Using Microsoft Sentinel to Detect Confluence CVE-2022-26134 Exploitation  

[

By Akshay Rohatgi and Randy Pargman

About this Student Research Project

Binary Defense’s mission is to make the world a safer place. In addition to the managed security services that we provide for our clients, one of the other ways we contribute is to provide training and real-world experience to up-and-coming new cybersecurity professionals through our classes and internship programs.

Typically, we work with university students and recent graduates, but during the process of reviewing applications for our summer internship program this year, we received a compelling application from a high school student named Akshay. Although he was not in a university program yet, he clearly had a deep interest in cybersecurity as evidenced by the competitions he had won, the projects he had published on GitHub, and his enthusiasm for security. So, we designed a special two-week program to give Akshay a chance to participate in a security research project.

Since Atlassian Confluence servers had recently come under wide-spread attack through exploitation of CVE-2022-26134 at the start of the Summer, this was a relevant and timely real-world event to focus on. This blog describes the research and development work that Akshay completed in just two weeks.

Research Goals

The end goal of the research project was to develop a custom detection query that would alert SOC analysts accurately when a Confluence server had been exploited. To get there, we needed to meet several goals along the way:

1. Set up a vulnerable version of Atlassian Confluence on a server in our research lab
2. Install a Microsoft Monitoring Agent on the server to forward logs to Microsoft Sentinel
3. Configure a “Custom Log” source to collect the Confluence access logs
4. Develop a custom Kusto Query Language (KQL) query to parse the Confluence logs and make them useful for queries
5. Create a KQL detection query that would accurately detect when the exploit and follow-on threat activity occurred
6. Add a custom Sentinel Alert to generate Incidents in Sentinel when the threat was detected
7. Successfully exploit the Confluence vulnerability (CVE-2022-26134) via a C2 implant and test the detection

Confluence Setup

CVE-2022-26134 is an OGNL injection vulnerability in Atlassian Confluence that leads to arbitrary remote code execution (RCE). One of the vulnerable versions was 7.13, which we were able to download from https://www.atlassian.com/software/confluence/download-archives. Afterwards we simply followed their installation guide for a Linux server (https://confluence.atlassian.com/doc/confluence-installation-guide-135681.html).   

After completing the installation, we made sure that the Confluence instance was only inside-facing in our research lab. We wanted to keep threat actors working inside our lab to stay interested and attempt to attack the Confluence instance.

Installing Microsoft Monitoring Agent

To detect threats from event logs, one must first forward the logs to a central server. This keeps the event records safe even if the attacker clears the logs later and allows a Security Operations Center (SOC) to detect threats and respond to them quickly.

For this project we used Microsoft Sentinel, an enterprise-grade cloud SIEM, to collect and manage the logs. Installation of the Microsoft Monitoring Agent for Linux was straightforward, using a script provided by Microsoft:

wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w [workspace ID goes here] -s [key goes here] -d opinsights.azure.com

Adding a Custom Log Source to Microsoft Sentinel

Once the Monitoring Agent was installed on the Confluence server and the “Heartbeat” events started flowing in to Sentinel, we had to configure Sentinel to collect the Confluence logs from the location where they are stored.

From Microsoft Sentinel, go to “Settings” and then “Workspace Settings” to find the configuration options for “Custom Logs”

Add a new log type, call it “ConfluenceAccess” and provide the path (including wildcards to match the date that ends each log file name): /opt/atlassian/confluence/logs/conf_access_log.*

Within about 30 minutes, the custom log should be activated, and you can query events in Sentinel using this KQL query (in the “Logs” section):

ConfluenceAccess_CL
| take 10

Parsing the Confluence Logs in Microsoft Sentinel

When the raw logs come into Sentinel, they are usable but not easy to query, because Confluence puts a lot of information into each line of the event log, separated by spaces. When Sentinel imports the events, it stores the information in a field simply called “RawData” exactly as Confluence sent it.

We can make this easier to search by telling Sentinel how to parse this record into fields with meaningful names. This is done by writing a KQL query that uses the “split” operator to break the RawData into sub-strings and the “extend” operator to create new fields.

let Confluence = ConfluenceAccess_CL
| extend RHOST = tostring(split(RawData, " ")[4])
| extend Verb = tostring(split(RawData, " ")[5])
| extend Access_URL = tostring(split(RawData, " ")[6])
| extend HTTP_Version = tostring(split(RawData, " ")[7])
| project-away RawData 
| order by TimeGenerated
;
Confluence

Run that query and then save it as a custom function named “Confluence” to make queries easier and more readable.

Detecting Confluence Exploitation with a KQL Query

Now that we have event logs set up and a custom parsing function makes them easy to query, we can design a KQL query that will detect the pattern that we expect to see in the Confluence logs when an attacker exploits the CVE-2022-26134 vulnerability.

In this case, the detection pattern is quite straightforward – look for any access request where the request URL contains %7B, which is the HTTP encoded character entity for “{“

In addition to this detection based on the URL requested, there is another approach to detect when the Java process that runs Confluence spawns an unexpected child process, indicating that an attacker may have forced it to run a program (remote code execution):

“getconf” and “java” are system binaries that are normally executed by confluence, so we can safely exclude those in our queries.

Developing a Microsoft Sentinel Alert

Based on these detection patterns, we created two custom alerts in Sentinel that will create Incidents and alert the SOC whenever suspicious events are detected.

From the Sentinel Logs workspace, click the “New Alert Rule” dropdown and select “Create Azure Sentinel Alert”

Add basic rule metadata, including the rule name, description, techniques, and severity level.

Then we can move on to setting up the “Rule Logic.” First verify the KQL query that will trigger the alert:

You can then map event details to various entities recognized by Sentinel to make it easier for SOC analysts to investigate an incident. In this case we mapped the RHOST field in the event to an IP entity.

We also configure the rule to check for an attack attempt every 5 minutes.

 
Also make sure that each event does not trigger a new alert, to not overload an SOC analyst with redundant information.

We can now enable Sentinel incidents so we can group multiple like alerts into a single incident. Again, to make it easier for SOC analysts to investigate security incidents. Here, we grouped alerts into an incident by IP entity.

Exploiting Confluence and Testing Detection

Now we can test our detection rules. We are going to generate an MTLs Windows beacon from a Sliver C2 server and run it on a windows PC connected to our research lab network. Of course, it isn’t strictly necessary to use a C2 framework and an implant to trigger the exploit, but doing so more closely replicates the activities of an attacker who managed to trick an end user into running some malware and is now moving laterally by exploiting vulnerable servers.

We get a call back from the beacon and can get a shell session on the machine. We then use PowerShell to exploit the Confluence application.  We ran the exploit command 3 times to trigger multiple alerts.

That’s it! No wonder there has been so much uproar about this exploit. Anyway, we can now wait to see if Sentinel will alert us about the attack.

And it does! Our first alert, the attack attempt is detected. This incident is comprised of 3 alerts warning of a potential RCE attack based on suspicious access requests. Let us check to see if our other alert went off.

Looks like our alerts for uncommon system utilities being executed by Java have also gone off, indicating an attack occurred. Three alerts also account for this incident.

Conclusion

From this project, we can quickly detect CVE-2022-26134 exploitation attempts using Microsoft Sentinel. This will help SOC analysts effectively and efficiently respond to security incidents related to CVE-2022-26134.

While Micrsoft Sentinel can simplify log collection and the creation of detection rules, not all security teams have the in-house bandwidth or skillset to implement, tune, and manage Sentinel. With our Microsoft Sentinel Managed Security Service, our Microsoft Sentinel experts gets your team deployed, monitoring, and responding to alerts faster while our SOC Analysts and Threat Hunters have their eyes on your environment 24/7/365 to make sure no alert goes unnoticed.