The OAST with the most

Attackers use tools to scan networks for vulnerabilities and sometimes these tools can be used to our advantage. Here we describe one of the more popular vulnerability scanning tools and techniques, and demonstrate how net defenders and analysts can leverage them for threat intelligence purposes.

Out-of-band application security testing (OAST) is a method for finding exploitable vulnerabilities in a web application by forcing a target to call back to a piece of infrastructure controlled by the tester. This type of testing can be facilitated by OAST tools such as those provided by Project Discovery (interact.sh) and Port Swigger (Burp Collaborator). These tools have become increasingly popular in recent months and currently account for a large proportion of scanning activity in general.

Below we’ll take a closer look at Project Discovery’s OAST service interact.sh and give insights into related traffic. Key takeaways:

• Out-of-band application security testing (OAST) tools, such as Project Discovery’s interact.sh are becoming increasingly popular for reconnaissance purposes.
• Project Discovery currently accounts for roughly half of all Log4j (CVE-2021-44228) attacks and a quarter of total attacks observed by Lacework Labs. More recently, the tool has been utilized for Spring4Shell (CVE-2022-22965) attacks
• Project Discovery configurations, aka Nuclei templates, can be leveraged for threat intelligence and network defense.
• Lacework Labs is releasing a set of tools for analyzing Project Discovery traffic.

Here are the technical details:

An examination of Lacework web logs following the release of the Log4j proof-of-concept revealed numerous exploit attempts from various sources. One trend that became apparent was the presence of the domain “interact.sh” among the Log4j exploit artifacts:

Figure 1. interact.sh artifacts in Nginx logs

This domain is leveraged by Project Discovery’s OAST service of the same name — interact.sh. interact.sh is used by Project Discovery’s Nuclei scanner which offers scanning against various protocols.

Figure 2. Non-OAST and OAST Log4j exploit attempts by day

Though interact.sh is the best-known Project Discovery OAST domain, in mid-January, the following default servers were added:

• oast.pro
• oast.live
• oast.site
• oast.online
• oast.fun
• oast.me

These domains were quickly adopted and have almost completely replaced the interact.sh domain for Log4j exploitation. However, the interact.sh domain continues to be regularly used for other vulnerabilities.

Detection of Log4j exploits from Project Discovery is relatively simple and only requires the presence of the previously mentioned OAST domains and a Log4j artifact. That said, Log4j accounted for only a small fraction of overall Project Discovery OAST traffic. Additionally, much of the Project Discovery traffic is not OAST related and doesn’t leverage the OAST domains at all. For detection of these non-OAST artifacts, one can look for the presence of one of several user agents used by Project Discovery’s Nuclei scanner. Examination of the Nuclei source code on Github revealed 32 user agents that are cycled through during testing. While these are easy to switch out, a large amount of traffic leverages them by default.

Figure 3. Hardcoded UAs in Golang source code

Analysis of Project Discovery activity revealed Cloudflare and DigitalOcean as the top originators. DigitalOcean was likewise one of the top traffic sources for Log4j exploits during the initial wave. The following is a breakdown of Project Discovery traffic origins over a month-long period. Note: In order for a scan to be linked to Project Discovery, the IP had to have been observed with two or more of the previously mentioned hard-coded user-agents as well as have used one of the known Project Discovery exploits and/or OAST domains.

Figure 4. Project Discovery traffic sources

Nuclei Analysis

Project Discovery traffic can also be identified by examining Nuclei scanner configurations provided by the Project Discovery community. These configurations, known as Nuclei templates, are YAML files that contain all the necessary data to test for a specific vulnerability or exploit. For example:

Figure 5. Nuclei Templates

The Nuclei YAML format (Figure 5) is useful for both Project Discovery users and threat intelligence. On the threat intel side, these configurations can easily be imported into a database that allows for semi-structured queries. For example, Lacework Labs cloned the repository containing Nuclei configurations, converted it to JSON, and then imported it into Snowflake for analysis.

Figure 6. Nuclei Templates in Snowflake

Upon successful import, one can derive various insights such as the total count of CVEs or CVE counts ranked by year. For example:

select SPLIT(YAML:id,'-')[1]::string as cve_year,count(*) as cvecount from NUCLEI_TEMPLATESNEW 
WHERE PATH LIKE '%/CVE%' group by cve_year order by cvecount desc;

Not all of the Nuclei templates use OAST methods. OAST configs can be identified with the interact URL format string: {{interactsh-url}}. Example YAML for Log4j.

Figure 7. OAST formatting strings

Another use case is for artifact extraction. For example, by querying the Nuclei YAML keys we can map a given exploit name and description to the associated artifact that would appear in traffic. This can be used for rule development and to obtain context on any attack, not just those originating from Project Discovery. For example:

with artifacts as (select yaml:id::string as id,yaml:info.name::string as Description,value as uri from NUCLEI_TEMPLATESNEW, lateral flatten(input => yaml:requests[0]['path']))
SELECT id,Description, SPLIT(uri,'{{BaseURL}}')[1]::string as artifact from artifacts where artifact not like '';

Using this as a filter, we can return all the exploits in the templates that leverage OAST. This output has been provided in the  Lacework Labs Github reference.

select YAML:id::string as Id,YAML:info.name::string as Description from Nuclei_templates where YAML like '%{interactsh-url}%';

Spring4shell Update

On April 1st 2022, Project Discovery’s nuclei scanner added a configuration for the Spring4Shell RCE
(CVE-2022-22965). This configuration is not an OAST implementation, however it does write a jsp file named /checkexploit.jsp with the contents ‘SPRING_CORE_RCE’. Shortly after this update, Lacework began seeing GET requests for this.

Figure 8. Old Spring4Shell config

Interestingly, in the days after the update, Spring4Shell scanning using the template significantly declined, relative to other Project Discovery traffic. On April 4th, a new configuration for Spring4Shell was added. This version doesn’t write a jsp file but rather initiates a callback using OAST.

Figure 9. Spring4Shell config – OAST version

Tools

Lacework Labs has released two of the tools used in this research. Both use Snowflake for analysis. The first tool queries Nginx logs from Scalyr for any OAST activity originating from Project Discovery’s interact.sh, though it can be modified to run any query. Results are saved to Snowflake for further analysis.

The second tool processes the Nuclei templates from a local Project Discovery repository. Once the templates have been imported, queries such as those in the previous section can be performed.

OAST tools such as those offered by Project Discovery are part of a larger trend of leveraging open source security tools for malicious purposes. In the case of Project Discovery, interact.sh is effectively “reconnaissance as a service” and can be advantageous for attacker operational security. Because the tool is legitimate and leveraged by researchers and penetration testers, malicious usage is likely to be indistinguishable. This reduces attacker footprints and allows for separation of reconnaissance and exploitation activities; it also allows attackers to only use their dedicated attack infrastructure against known vulnerable hosts.

Related tools used in Snowflake analysis are available on Lacework Labs’s Github. For more content like this follow us on Twitter and LinkedIn!