Researchers at Palo Alto Networks discovered an automated scanning tool called Swiss Army Suite (S.A.S) during regular monitoring of telemetry data. Our research indicates that attackers used this tool to perform vulnerability scans not only on our customers' web services but also on various online websites.
Our structured query language (SQL) injection detection model detected triggers containing unusual patterns that did not correlate to any known open-source or commercial automated vulnerability scanning tool. A tool generating this sort of traffic could have additional payloads that could potentially bypass web application firewalls (WAFs) or any other traffic filtering device that bases detection on known patterns of vulnerability scanning tools.
After investigating the pattern across the internet, we discovered cached Google results showing attempted SQL injections with the same string patterns reported by several individuals in their online security device log files. However, at that time, we were still determining who the users of this specific tool were. The tool information is valuable from a defense standpoint, regardless of whether the detection strategy provided by the network security administrator is signature-based or machine learning-based.
Palo Alto Networks customers are better protected from the threats discussed in this article through our Network Security solutions, such as Cloud-Delivered Security Services including Advanced WildFire and Advanced Threat Prevention. Prisma Cloud web application and API security (WAAS) monitoring detects SQL injection attacks targeting cloud-based web applications and API applications. Cortex behavioral rules monitor for specific malicious activity.
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Red teamers and threat actors frequently use commercial and open-source tools to scan for vulnerabilities. Researchers have already analyzed and documented the traffic patterns in open-source/commercial vulnerability scanning tools like Nessus and OpenVAS.
It is much more challenging to research the payloads used by privately developed tools because threat actors typically share these tools in underground forums, making it difficult to create detections for them. In these scenarios, machine learning models play a crucial role in behavioral detection.
It is important to have a strategy that can identify and neutralize unknown attacks for good defense. Machine learning plays a crucial role in achieving this goal.
A machine learning model should be able to identify such activities whether the tool is commercial or not. However, identifying private tools is much more challenging due to the lack of patterns required to train the machine learning model.
Without knowledge of these patterns, attacks from private tools may successfully deliver malicious payloads, propelling malicious actors another step closer to their goals such as:
During routine examination of cloud detection triggers captured by our telemetry sensors, we noticed some payload structure similarities with a common string pattern (%27nvOpzp;%20AND%201=1%20OR%20(%3C%27%22%3EiKO))). These similarities occurred among several payloads marked malicious by the cloud-based machine learning model designed to detect SQL injection. After some manual analysis, our researchers could not fully determine whether this traffic corresponded to a known vulnerability scanning tool or not.
Figure 1 shows several scan attempts in our telemetry data.
Figure 2 shows the hits our researchers observed in various geolocations.
To better understand the volume of websites that attackers could target using this tool for scanning, our researchers executed a Google search lookup using the pattern we detected from our cloud telemetry system:
At the time of this query, this term returned 703,000 search results. Figure 3 shows the Google search results that proved to be interesting.
Each Google result appears to include the results of a website's search query, which also includes the SQL injection query string. This indicates that Google's cache mechanism apparently stored these results.
Figure 3 shows an example of the link that points to the actual webpage search engine and the string used for the search that includes the attack SQL injection pattern. The full URL pops out by hovering the mouse over each link, including the target web resource, the parameters and the injection points used by the tool.
After we made several searches online through search engines and code repositories, trying to map out the payload content and its related tool, our search came up empty. However, we got a hit when searching underground forums commonly used by attackers and script kiddies.
The tool S.A.S advertises itself as a multifunctional pentesting tool with different features, such as the Dork-based checker and generator. "Dork" is a common term for using special search operators supported by an online search engine. Dorks are usually used to find sensitive information that is hard to find through traditional search methods.
For instance, in the tool's default configuration, it uses the inurl: dork to look for a particular pattern in the URL of the results and the site: dork to narrow the results focused on a specific domain.
The S.A.S tool supports the following features:
Unlike most common vulnerability scanning software, this tool is not commercially available to the public through regular software acquisition methods. However, the version shared on this website offers a cracked version to its forum members. This cracked version is likely meant for users that fall into the attacker profile category rather than regular red teamers or security researchers. Figure 4 shows the forum post.
Once our research team knew the tool's name, we performed a more comprehensive check looking for potential tool versions available on threat intel sample sources by trying a string-based search. Figure 5 shows a list of the additional samples we found during research, which contained the same SQL injection attack string pattern.
Figure 6 shows the different options provided by the tool. Option 5 is the SQL Vuln Scanner feature that this research focuses on.
The tool provides different features, including the execution of an SQL injection scan. It also supports proxy types such as Proxyless, HTTP and SOCKS5.
The final selection of information consists of an input file containing the IP address and port of the target application, which should contain the full URL including the parameters that set the SQL injection points.
Also, the tool uses a configuration from which the user can fully customize all features. For the SQL injection feature, it supports the control of the threads and timeout thresholds. Figure 7 shows the configuration file and its current values that the tool uses by default.
To determine what its traffic looks like during the tool's execution, we created a local testing scenario against a vulnerable web application in a controlled environment. This proof of concept used the Damn Vulnerable Web Application (DVWA) framework. The DVWA tool is designed to train individuals in web security by allowing students to exploit intentionally introduced vulnerabilities within the framework.
Figure 8 shows a screen capture of an HTTP request targeting a running instance of the DVWA suite that has the SQL injection vulnerability module enabled.
S.A.S can attempt attacks against several injection points (i.e., parameters) of a target web application.
Figure 9 shows two main parts. The first shows the HTTP request containing the payload set on the "id=" and "Submit" injection points. The second shows the HTTP response confirming the SQL injection exception thrown by the MariaDB (a fork of MySQL) database server after the vulnerability scan has been finished. This exception indicates that the web application is vulnerable to SQL Injection.
Once the tool completes the vulnerability scan, the results window displays the results of all affected relational database management systems. Figure 10 shows that the scan found a SQL injection vulnerability in an application using MySQL as a relational database management system (RDBMS).
As seen in Figure 10 above, this tool supports up to 27 relational databases and one web application firewall (WAF).
The tool creates a new log file upon scan completion. The scan results use the current date as the folder name, and the tool also generates a new filename based on the DBRM found in the scan. In this case, the file name is mysql.txt. This file contains the URL that the tool found vulnerable to SQL injection.
To identify which countries the scans originated from, we used telemetry data from our ATP cloud to perform a search using the attack pattern. We then grouped the results by source IP addresses.
The results shown in Figure 11 indicate that the main use of this tool primarily came from four countries:
These results are based on telemetry collected by Palo Alto Networks appliances. Other metrics generated based on the use of the tool might not have similarities with the presented results.
Non-commercial tools usually support uncommon features, such as the Dork Checker or Anti-Public. These features are not traditionally found in commercial tools but are present in the S.A.S. tool. These features would allow malicious users to develop a more complex attack strategy and launch more precise and effective vulnerability scans.
From a defensive perspective, it is useful to differentiate between an automated scan and an actual attack. It is critical to know how to identify the capabilities of both closed-source commercial tools and restricted-access tools shared in underground forums. We tested different versions of S.A.S against a web application vulnerable to SQL injection.
We would like to extend our acknowledgements to Doel Santos, Nina Smith and Rashmi Reddy for their help on this research article.
We have tested all malicious payloads generated by the S.A.S tool against our Next-Generation Firewall equipped with the ATP machine learning model for detecting SQL injection to confirm the attack detection and blocking of the traffic. It was able to effectively prevent a zero-day exploit attempt.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.