IBM Security QRadar

NOTE: We will update this blog as new information and techniques are refined.

updated the AQL payload search to use a broader regex to catch some cases of Evasion.
******

***
The Log4j vulnerability is complex, and its full implications are still being researched. Organizations should rely on a diverse set of detection methods and tools to identify vulnerable applications or to verify remediation, as reliable detection techniques will vary from instance to instance of the vulnerability. In addition, teams should use forms of manual inspection for particularly sensitive applications.
***



A serious vulnerability is impacting our organizations, known as Log4Shell. It impacts log4j, a popular logging component used within applications developed in Java. It allows for remote code execution and poses a very serious threat.

Log4shell leverages a feature in log4j which performs lookups against the logs it receives. An attacker can exploit this by sending requests to a Web Application that will get logged directly such as user agents or requested URLs. When the application writes this to the log using log4j the lookups are performed. The lookups the attacker will trigger will cause the log4j to retrieve and execute untrusted content which can be used to gain control of the process.  You can find some additional information in this post: How Log4j Vulnerability Could Impact You

We are Tracking the response on IBM Products in this PSIRT: An update on the Apache Log4j CVE-2021-44228 vulnerability

There are several tools which can be used to detect this exploit in use, in this blog we will focus on configuring your QRadar SIEM to detect the attempted execution and exploitation of log4j. 

As always, we are maintaining a Public Collection on this issue in the IBM X-Force Exchange Public Collection: Log4j Zero-Day Vulnerability . Here you will find our latest information on this vulnerability also how to detect and remediate it. 

Real-time Detection of Log4Shell using QRadar

Detection of Log4Shell exploit in realtime will involve a new Custom Rule within QRadar. With this rule we will be attempting to detect as many permutations of the exploit as possible while attempting to optimize performance within the realtime pipeline. To do this we are going to need to identify the event properties that could indicate exploit.

The properties identified so far include:

URL
URL Query String
UrlHost
URL Path
User Agent
Referrer URL
Request Site
Request URI
API Path

NOTE: The more properties you include the harder the rule has to work, however you want to ensure you have full coverage of the possible fields. If you notice performance impact after creating this rule you could consider limiting it to particular log sources or networks.

To test these in the most efficient way possible we will create two building blocks to compare the properties to regular expressions. The regular expressions we are going to use are:

(?i)(\$|%24)(\{|%7[bB])(lower|upper|env|::-\w+|base64)
(?i)(\$|%24)(\{|%7B)[^\}]*?j.*?n.*?d.*?i

NOTE: More Regex's may be added here as more patterns are found to work

To define our first building block we need to go to the QRadar Rule editor and select the option to create a new event rule from the Actions Menu:

type 'reg' into the filter box and select the test "when any of these properties match this regular expression"

Configure the properties of the test to include the properties you wish to monitor and input the first regular expression from the block above:

Next in the upper right of the rules editor click "Export as Building Block"

Assign the building block the name "BB: Log4Shell Evasion Pattern 1" and click Save


The rule editor will reset allowing you to add the test "when any of these properties match this regular expression" again. Add the test and fill it out with the same properties and the next regex from the block above:

From the upper right of the editor select "Export as Building Block' again and save the new Building block with the name "BB: Log4Shell Base Pattern 1".

The rule editor will reset again allowing us to assemble our final rule bringing the two regular expressions together. To do this we will select the test "when an event matches any|all of the following rules"

Select the rules component of the test and add the two Building blocks we just created to the test as follows

Which results in a test that looks like this:

Assign the rule the name "Detect Potential Log4Shell Activity" and click next

On the Response page we will want to configure the rule to create an offense for the traffic that has been detected. Start by clicking “Ensure the detected event is part of an offense” in the Rule Action section and Index the offense based on “Source IP” 

In the Rule Response section select “Dispatch New Event”. Configure your Event Name to be “Detected Potential Log4Shell Activity” with a description of “An event was found that could be associated with Log4Shell CVE-2021-44228” 

Select the High Level category of “Potential Exploit” and a low level category of “Potential Web Exploit’. Click “Ensure the dispatched event is part of an offense” and select the index by “Source IP”. In the “Offense Naming” Section select “This information should contribute to the name of the associated offense(s)”. 

In the response limiter section respond no more than 1 time per 1 minute per Source IP. 
Now click Finish to deploy the rule and begin monitoring.

***
NOTE: This rule is an example that could be modified to suit your specific system needs. Any feedback on your experiences is very welcome
***

Additional Detection of Log4Shell using known IOCs 

In addition to the pattern matching defined above several organizations are collecting known IOC’s related to Log4Shell exploitation. This data can be brought into QRadar for usage in the Real-time Detection patterns as well. 

To do this we will start by creating some reference sets in your QRadar system by navigating to the Administration Tab, then selecting “Reference Set Management”. 

First we will add a reference set called ‘Log4Shell IP IOCs of the type IP 

Next we will create 3 reference sets called “Log4Shell MD5 IOC”, “Log4Shell SHA1 IOC”, “Log4Shell SHA256 IOC” all of type “AlphaNumeric (Ignore Case)”

For the scope of this blog we will just populate these by hand using the IP addresses from the XForce Collection: https://exchange.xforce.ibmcloud.com/collection/4daa3df4f73a51590efced7fb90bc949  and the File Hashes from: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes 

This can be done in the Reference Set Management page by selecting the reference set from the list and adding the elements. 

Once the reference sets have been populated, we will create rules that leverage the data. First, we will create a rule that checks the incoming and outgoing IP addresses against the list of known exploiters: 

Next, we will create a rule to watch for the file hashes of known vulnerable versions of Log4j

Detect Historical instances of Log4Shell

QRadar can also detect historical instances of Log4Shell by searching through the data stored within the system. Do do this you can execute the following AQL query:

select QIDNAME(qid) AS "Event Name", sourceip AS "Source IP", destinationip AS "Destination IP", destinationport as "Destination Port",DATEFORMAT(devicetime, 'yyyy-MM-dd HH:mm:ss z') AS "Log Source Time",LOGSOURCENAME(logsourceid) AS "Log Source", SUM(eventcount)
from events where UTF8(payload) IMATCHES '.*\$(\{|%7B)[^\}]*?j.*?n.*?d.*?i.*' and devicetype != 105
Group by "Event Name","Source IP"
last 24 HOURS 

In addition to searching for this traffic based on the regex patterns you could search for potential connections based on the profile of the traffic within your environment. To do this we will search for Egress traffic on ports 389, 636, 1099 and 1389 which are the common network ports in use by this exploit. Additionally if you are using QNI or QFlow packet based collection you can search for application signatures. To do this with AQL the following query would be used:

For flows:

select sourceip, sourceport, destinationip, destinationport, applicationid, applicationname(applicationid), flowdirection, count(*) as "Flow Count"
from flows
where flowdirection = 'L2R' and fullMatchList != 100012 and fullMatchList != 100174 and ( destinationport in (53, 389, 636, 1099, 1389) OR applicationid in (536871002, 34810,21624, 1019, 536871006, 34801, 51341, 60109, 1017, 536870955) )
group by sourceip
last 24 hours

NOTE: we are excluding the “BB:FalsePositive: LDAP Server False Positive Events” and “BB:FalsePositive: DNS Server False Positive Events” as we expect these servers to be performing this traffic. These are excluded by removing matches against the events for their rule ID's

And on the event side we are going to do a similar query:

select QIDNAME(qid) AS "Event Name", sourceip AS "Source IP", destinationip AS "Destination IP", destinationport as "Destination Port",DATEFORMAT(devicetime, 'yyyy-MM-dd HH:mm:ss z') AS "Log Source Time",LOGSOURCENAME(logsourceid) AS "Log Source", SUM(eventcount) 
from events
where eventdirection = 'L2R' and destinationport in (53, 389, 636, 1099, 1389) and creeventlist != 100012 and creeventlist != 100174
Group by "Event Name","Source IP"
last 24 HOURS

Detecting Log4Shell Exploit using a Detection AQL Function

The AQL function we have created replicates the detection logic used in Florian Roth's log4shell-detector script; this looks to enhance detection without relying on regular expression pattern matching. Our AQL function brings this functionality into QRadar for both historical searching and real-time monitoring through rules meaning you can make full use of QRadar's custom rule engine and rule responses.

The AQL function takes two parameters: Payload and Maximum Distance. The Payload is any String you wish to have the analysis performed on - in our examples we use UTF8(payload) to pass a whole payload. The Maximum Distance is the number of characters between one character in the malicious string and the next, i.e., the number of characters between your '{' and your 'j' - in our examples we use a maximum distance of 40.

Note: Lower maximum distance values may result in the inability to detect highly obfuscated malicious strings. Higher maximum distance values may result in increase computational requirements which could impact performance and speed of searches/rules.


Through this post, I will look to guide you on uploading the custom function to QRadar, running historical searches, and setting up your first rule using this AQL function.

Uploading the Custom Function to QRadar

1. Download the latest release zip from https://exchange.xforce.ibmcloud.com/hub/extension/IBMQRadar:IBMContentPackageInternalThreat. Alternatively, you can create your own zip using the XML and LICENSE files found in the repository.
2. Navigate to the 'Admin' page on your QRadar UI and open 'Extensions Management' under the 'System Configuration' section.
3. Click the 'Add' button and upload the zip you downloaded in step 1.
   
4. Ensure 'Install immediately' is selected and click 'Add' to begin the install.
5. You will be prompted with a warning the extension is not signed. Proceed with the install.
6. Once you've progressed through all the install steps, the AQL function will be available for use in searches and custom rules.

Performing a Historical Search with the AQL Custom Function
As discussed earlier in this blog, we can perform an AQL search simply by going to the 'Log Activity' tab, changing the 'Quick Filter' drop-down to 'Advanced Search' (it may already be set to advanced search), and entering the following AQL search into the field.

select QIDNAME(qid) AS "Event Name", sourceip AS "Source IP", destinationip AS "Destination IP", destinationport as "Destination Port",DATEFORMAT(devicetime, 'yyyy-MM-dd HH:mm:ss z') AS "Log Source Time",LOGSOURCENAME(logsourceid) AS "Log Source", SUM(eventcount)
from events where EXPLOITDETECT::LOG4J(UTF8(payload),40) and devicetype != 105 and devicetype != 18
Group by "Event Name","Source IP"
last 24 HOURS ​

Note: AQL searching using the Log4j detection function can take a long time compared to the regular expression AQL searching. However, it should produce fewer false positives and provide detection for URL and base64 encoded malicious strings. Performing searches for larger time windows may have an impact on search performance across the SIEM.


Performing Real-Time Monitoring with the AQL Custom Function
We can perform real-time monitoring using QRadar's custom rule engine alongside the AQL custom function. As with the regex pattern matching rules discussed earlier, this rule is an example implementation of the AQL custom function and you should always design rules according to your system and environment needs.


As you can see in the above rule, we have limited the the use of this function to some key log source types (set log source types relevant to your environment). The above rule logic relies on the following two lines of logic:

'and when the event(s) were detected by one or more of these log source types'
'and when the event matches this AQL filter query'

You should ensure your log source type filter is processed before the AQL filter to ensure optimal rule speeds and CRE process utilisation.

Note: Using the AQL custom function in a very broad rule alongside large strings, such as UTF8(payload), can have an impact on the rule's efficiency as well as overall performance of the QRadar Custom Rule Engine. Please exercise caution when designing your rules.

Licenses and References
This AQL function was developed based on the logic provided by Florian Roth's log4shell-detector script (https://github.com/Neo23x0/log4shell-detector). As such, it is distributed under the log4shell-detector script's MIT license .

Thank you for Florian for his work on developing his Python script and maintaining it to stay on top of the growing obfuscation methods.

Using Kestrel Threat Hunting to find instances of Log4Shell in your environment

A project IBM Security has been sponsoring in the Open Cybersecurity Alliance is the Kestrel Threat Hunting Language, this is an OpenSource project that leverages the power of stix-shifter  to do federated threat hunting across multiple security platforms. The stix-shifter project currently supports over 29 data sources including every major SIEM.

A detection module was added to Kestrel for Log4Shell and details can be found here:
log4shell Detection.ipynb

Mitigation Recommendations & Additional Resources

Please see consult the X-Force collection for recommendations on remediation: Public Collection: Log4j Zero-Day Vulnerability 

There are a number of content extensions for QRadar that can expand your out of the box property extraction and rule content:
IBM QRadar Content Extension for Amazon AWS
IBM Security QRadar Custom Properties for Microsoft IIS
IBM Security QRadar Custom Properties for NGINX
IBM Security QRadar Custom Properties for Apache

Also See the Blog by Gladys Koskas on utilizing the new YARA App for QRadar: Enhance your detection of Log4j exploit (CVE-2021-44228) with the YARA App using this method you can search through your QRadar data using YARA rules ( for log4shell and other YARA rules! )

IBM Security X-Force will be hosting a webinar on December 15th discussing this vulnerability, register here: Log4j Zero-Day Vulnerability: What You Need to Know Now

References

https://www.lunasec.io/docs/blog/log4j-zero-day/
https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j_fields.yml 

#Highlights-home
#Highlights
#Featured-area-1-home
#Featured-area-1​​