Preâmbulo
Welcome to another installment of Okta threat research with Elastic. Previously, we have published articles exploring Okta’s core services and offerings. This article is dedicated to the practical side of cyber defense - setting up a robust Okta threat detection lab. Our journey will navigate through the intricacies of configuring a lab environment using the Elastic Stack, integrating SIEM solutions, and seamlessly connecting with Okta.
The goal of this article is not just to inform but to empower. Whether you're a seasoned cybersecurity professional or a curious enthusiast, our walkthrough aims to equip you with the knowledge and tools to understand and implement advanced threat detection mechanisms for Okta environments. We believe that hands-on experience is the cornerstone of effective cybersecurity practice, and this guide is crafted to provide you with a practical roadmap to enhance your security posture.
As we embark on this technical expedition, remember that the world of cybersecurity is dynamic and ever-evolving. The methods and strategies discussed here are a reflection of the current landscape and best practices. We encourage you to approach this guide with a mindset of exploration and adaptation, as the techniques and tools in cybersecurity are continually advancing.
So, let's dive into our detection lab setup for Okta research.
Pré-requisitos
For starters, an Okta license (a trial license is fine) is required for this lab setup. This will at least allow us to generate Okta system logs within our environment, which we can then ingest into our Elastic Stack.
Secondarily, after Okta is set up, we can deploy a Windows Server, set up Active Directory (AD), and use the AD integration in Okta to sync AD with Okta for Identity and Access Management (IAM). This step is not necessary for the rest of the lab, however, it can help extend our lab for other exercises and scenarios where endpoint and Okta data are both necessary for hunting.
Sign up for Okta Workforce Identity
We will set up a fresh Okta environment for this walkthrough by signing up for a Workforce Identity Cloud trial. If you already have an Okta setup in your environment, then feel free to skip to the Setting Up the Elastic Stack section.
Once signed up for the trial, you are typically presented with a URL containing a trial license subdomain and the email to log into the Okta admin console.
To start, users must pivot over to the email they provided when signing up and follow the instructions of the activation email by Okta, which contains a QR code to scan.
The QR code is linked to the Okta Verify application that is available on mobile devices, iOS and Android. A prompt on the mobile device for multi-factor authentication (MFA) using a phone number and face recognition is requested.
Image 1: Setting up Okta Verify through a mobile device
Once set up, we are redirected to the Okta admin console to configure MFA using Okta Verify.
Image 2: The Okta Admin console
At this point, you should have a trial license for Okta, have setup MFA, and have access to the Okta admin console.
Setting up your free cloud stack
For this lab, we will use a free trial of an Elastic Cloud instance. You also have the option to create the stack in Amazon Web Services (AWS), GCP, or Microsoft Azure if you’d like to set up your stack in an existing cloud service provider (CSP). Ensure you enable MFA for your Elastic Cloud environment.
Once registered for the free trial, we can focus on configuring the Elastic Stack deployment. For this lab, we will call our deployment okta-threat-detection and deploy it in GCP. It is fine to leave the default settings for your deployment, and we recommend the latest version for all the latest features. For the purposes of this demo, we use the following:
- Name: okta-threat-detection
- Cloud provider: Google Cloud
- Region: Iowa (us-central1)
- Hardware profile: Storage optimized
- Version: 8.12.0 (latest)
The option to adjust additional settings for Elasticsearch, Kibana, Integrations, and more is configurable during this step. However, default settings are fine for this lab exercise. If you choose to leverage the Elastic Stack for a more permanent, long-term strategy, we recommend planning and designing architecturally according to your needs.
Once set, select “Create deployment” and the Elastic Stack will automatically be deployed in GCP (or whatever cloud provider you selected). You can download the displayed credentials as a CSV file or save them wherever you see fit. The deployment takes approximately 5 minutes to complete and once finished, you can select “Continue” to log in. Congratulations, you have successfully deployed the Elastic Stack within minutes!
Image 3: Your newly deployed Elastic stack
Setup Fleet from the Security Solution
As a reminder, Fleet enables the creation and management of an agent policy, which will incorporate the Okta integration on an Elastic Agent. This integration is used to access and ingest Okta logs into our stack.
Create an Okta policy
For our Elastic Agent to know which integration it is using, what data to gather, and where to stream that data within our stack, we must first set up a custom Fleet policy we’re naming Okta.
To set up a fleet policy within your Elastic Stack, do the following in your Elastic Stack:
- Navigation menu > Management > Fleet > Agent Policies > Create agent policy
- Enter “Okta” as a name > Create Agent Policy
Image 4: Fleet agent policies page in Elastic Stack
Setup the Okta integration
Once our policy is established, we need to install the Okta integration for the Elastic Stack we just deployed.
By selecting the “Okta” name in the agent policies that was just created, we need to add the Okta integration by selecting “Add integration” as shown below.
Image 5: The Okta integration within the agent policies
Typing “Okta” into the search bar will show the Okta integration that needs to be added. Select this integration and the following prompt should appear.
Image 6: The Okta Integration page
By selecting “Add Okta” we can now begin to set up the integration with a simple step-by-step process, complimentary to adding our first integration in the Elastic Stack.
Image 7: Adding integrations into the Elastic Stack
Install the Elastic Agent on an endpoint
As previously mentioned, we have to install at least one agent on an endpoint to access data in Okta, associated with the configured Okta policy. We recommend a lightweight Linux host, either as a VM locally or in a CSP such as GCP, to keep everything in the same environment. For this publication, I will use a VM instance of Ubuntu 20.04 LTS VM in Google’s Compute Engine (GCE). Your endpoint can be lightweight, such as GCP N1 or E2 series, as its sole purpose is to run the Elastic Agent.
Select the “Install Elastic Agent” button and select which host the agent will be installed on. For this example, we will be using a Linux host. Once selected, a “Copy” option is available to copy and paste the commands into your Linux console, followed by execution.
Image 8: Install Elastic Agent
Create an Okta token
At this point, we need an API key and an Okta system logs API URL for the integration setup. Thus, we must pivot to the Okta admin console to create the API token.
Image 9: Access the Okta Admin console
From the Okta admin console, select the following:
- Security > API > Tokens
- Select the “Create token” button
In this instance, we name the API token “elastic”. Since my administrator account creates the token, it inherits the permissions and privileges of my account. In general, we recommend creating a separate user and scoping permissions properly with principle-of-least-privilege (PoLP) for best security practices. I recommend copying the provided API token key to the clipboard, as it is necessary for the Okta integration setup.
Image 10: Copy your API token
We also need to capture the Okta API Logs URL, which is our HTTPS URL with the URI /api/v1/logs or system logs API endpoint.
For example: https://{okta-subdomain}.okta.com/api/v1/logs
The Elastic Agent, using the Okta integration, will send requests to this API URL with our API token included in the authorization header of the requests as a Single Sign-On for Web Systems (SSWS) token. With this information, we are ready to finalize our Okta integration setup in the Elastic Stack.
Add Okta integration requirements
Pivoting back to the Okta integration setup in the Elastic Stack, it requires us to add the API token and the Okta System logs API URL as shown below. Aside from this, we change the “Initial Interval” from 24 hours to 2 minutes. This will help check for Okta logs immediately after we finish our setup.
Image 11: Configure log collection
Once this information is submitted to the Okta integration setup, we can select the “Confirm incoming data” button to verify that logs are properly being ingested from the Elastic Agent.
Image 12: Preview data from Okta
While we have confirmed that data is in fact being ingested from the Elastic Agent, we must also confirm that we have Okta-specific logs being ingested. I would suggest that you take a moment to pivot back to Okta and change some settings in the admin console. This will then generate Okta system logs that will eventually be extracted by our Elastic Agent and ingested into our Elastic Stack. Once completed, we can leverage the Discover feature within Kibana to search for the Okta system logs that should have been generated.
The following query can help us accomplish this - event.dataset:okta*
Image 13: Use Discover to explore your Okta data
If you have managed to find Okta logs from this, then congratulations rockstar, you have successfully completed these steps:
- Signed up for Okta Workforce Identity with a trial license
- Deployed a trial Elastic stack via cloud.elastic.co
- Deployed an agent to your host of choice
- Created an Okta policy
- Setup the Okta integration
- Created an Okta API token
- Confirmed incoming data from our Elastic agent
Enable Okta detection rules
Elastic has 1000+ pre-built detection rules not only for Windows, Linux, and macOS endpoints, but also for several integrations, including Okta. You can view our current existing Okta rules and corresponding MITRE ATT&CK coverage.
To enable Okta rules, complete the following in the Elastic Stack:
- Navigation menu > Security > Manage > Rules
- Select “Load Elastic prebuilt rules and timeline templates”
- Once all rules are loaded: a. Select “Tags” dropdown b. Search “Okta” c. Select all rules > Build actions dropdown > Enable
Image 14: Searching for Out-of-the-Box (OOB) Okta Detection Rules
While we won’t go in-depth about exploring all rule information, we recommend doing so. Elastic has additional information, such as related integrations, investigation guides, and much more! Also, you can add to our community by creating your own detection rule with the “Create new rule” button and contribute it to our detection rules repository.
Let’s trigger a pre-built rule
After all Okta rules have been enabled, we can now move on to testing alerts for these rules with some simple emulation.
For this example, let’s use the Attempt to Reset MFA Factors for an Okta User Account detection rule that comes fresh out-of-the-box (OOB) with prebuilt detection rules.
Image 15: Enabling an OOB Okta detection rule to test alerting
To trigger, we simply log into our Okta admin console and select a user of choice from Directory > People and then More Actions > Reset Multifactor > Reset All.
Image 16: Resetting MFA for a user in Okta
Once complete, logs will be ingested shortly into the Elastic Stack, and the Detection Engine will run the rule’s query against datastreams whose patterns match logs-okta*. If all goes as expected, an alert should be available via the Security > Alerts page in the Elastic stack.
Image 17: Alert page flyout for triggered OOB Okta detection rule
Let’s trigger a custom rule
It is expected that not all OOTB Okta rules may be right for your environment or detection lab. As a result, you may want to create custom detection rules for data from the Okta integration. Allow me to demonstrate how you would do this.
Let’s assume we have a use case where we want to identify when a unique user ID (Okta Actor ID) has an established session from two separate devices, indicating a potential web session hijack.
For this, we will rely on Elastic’s piped query language, ES|QL. We can start by navigating to Security > Detection Rules (SIEM) > Create new rules. We can then select ES|QL as the rule type.
Image 18: Create new rule Kibana page in Elastic security solution
To re-create Okta system logs for this event, we would log in to Okta with the same account from multiple devices relatively quickly. For replication, I have done so via macOS and Windows endpoints, as well as my mobile phone, for variety.
The following custom ES|QL query would identify this activity, which we can confirm via Discover in the Elastic Stack before adding it to our new rule.
Image 19: Testing ES|QL query in Elastic Discover prior to rule implementation
Now that we have adjusted and tested our query and are happy with the results, we can set it as the query for our new rule.
Image 20: Creating new custom detection rule with ES|QL query logic
Image 21: Enabled custom detection rule with ES|QL query for Okta threat
Now that our rule has been created, tested, and enabled, let’s attempt to fire an alert by replicating this activity. For this, we simply log into our Okta admin console from the same device with multiple user accounts.
As we can see, we now have an alert for this custom rule!
Image 22: Triggered alert for events matching custom detection rule
Bonus: synchronize Active Directory (AD)
As discussed in our previous Okta installation, a core service offering in Okta is to synchronize with third-party IAM directory services such as AD, Google Workspace, and others. Doing so in your lab can enable further threat detection capabilities as cross-correlation between Windows logs and Okta for users would be possible. For this article, we will step through synchronizing with AD on a local Windows Server. Note - We recommend deploying a Windows Elastic Agent to your Windows Server and setting up the Windows and Elastic Defend integrations for additional log ingestion.
- Setup your Windows Server (we are using WinServer 2019)
- Deploy the Okta AD agent from your Okta admin console a. Directory > Directory Integrations b. Add Directory > Add Active Directory
- Walk through guided steps to install Okta AD agent on Windows Server a. Execution of the Okta Agent executable will require a setup on the Windows Server side as well
- Confirm Okta AD agent was successfully deployed
- Synchronize AD with Okta a. Directory > Directory Integrations b. Select new AD integration c. elect “Import Now” Choose incremental or full import
- Select which users and groups to import and import them
Image 23: Successful Okta agent deployment and synchronization with AD
Once finished, under Directory in the Okta admin console, you should see people and groups that have been successfully imported. From here, you can emulate attack scenarios such as stolen login credentials locally (Windows host) being used to reset MFA in Okta.
Additional considerations
While this is a basic setup of not only the Elastic Stack, Okta integration, and more for a threat research lab, there are additional considerations for our setup that are dependent on our research goals. While we won't dive into specifics nor exhaust possible scenarios, below is a list of considerations for your lab to accurately emulate an enterprise environment and/or adversary playbooks:
- Is Okta my IdP source of truth? If not, set up a third party such as Azure AD (AAD) or Google Workspace and synchronize directory services.
- Will I simulate adversary behavior - for example, SAMLjacking? If so, what third-party integrations do I need that leverage SAML for authentication?
- Do I want to research tenant poisoning? If so, should I set up a multi-tenant architecture with Okta?
- Do I need separate software, such as VPNs or proxies, to emulate attribution evasion when attempting to bypass MFA?
- What other tools, such as EvilGinx, let me attempt phishing playbooks, and what is the required set up in Okta for these exercises?
- How should I capture authorization codes during OAuth workflows, and how can I replay an exchange request for an access token?
- For password spraying or credential stuffing, which third-party applications should I integrate, and how many should suffice for accurate detection logic?
- How might I explore lax access policies for user profiles?
Takeaways
In this guide, we've successfully navigated the setup of an Okta threat detection lab using the Elastic Stack, highlighting the importance of safeguarding SaaS platforms like Okta. Our journey included deploying the Elastic Stack, integrating and testing Okta system logs, and implementing both pre-built and custom detection rules.
The key takeaway is the Elastic Stack's versatility in threat detection, accommodating various scenarios, and enhancing cybersecurity capabilities. This walkthrough demonstrates that effective threat management in Okta environments is both achievable and essential.
As we wrap up, remember that the true value of this exercise lies in its practical application. By establishing your own detection lab, you're not only reinforcing your security posture but also contributing to the broader cybersecurity community. Stay tuned for additional threat research content surrounding SaaS and Okta, where we'll explore common adversary attacks against Okta environments and detection strategies.