Vulnerability Scanner Logs: OWASP Zep Attack Proxy (OWASP ZAP)

There are multiple web application security scanning tools (vulnerability scanners) available, each will leave a trail in your logs. Knowning what these tools are doing can be critical to your organization as they are available to both good and bad actors. This means that what might seem as a benign request could be a bad actor looking for a vulnerability to exploit.

We recommend blocking this type of activity unless you have an internal team performing these actions, and in those instances we encourage you to whitelist their environment to perform the scan and block the rest of the world.

In this article, we will dive into what the OWASP Zed Attack Proxy (ZAP) scanner is doing and provide a series of logs that you can use to understand its actions and hopefully help with your defense posture.

This test uses the OWASP ZAP tool in its default configuration. We use it to scan one of our honeypot domains. Note that vulnerability scanners can be very noisy. Against a vanilla WordPress instance, with a default theme, it generated over 10,000 web requests (10,000 logs).



1- Starting the scan

The OWASP ZAP too is a web application scanner. It scans websites (web app), not the whole server. When you start the scan, it asks for a target (domain or IP) and from there it emulates a browser and start to "visit" the pages of the site.

Trunc - OWASP ZAP - Interface


Looking at the logs, the initial queries are normal and don't raise any flags:

192.1.a.a - - [14/Sep/2022:15:15:55 +0000] "GET / HTTP/1.1" 200 60908 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:55 +0000] "GET / HTTP/1.1" 200 56469 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:55 +0000] "GET /sitemap.xml HTTP/1.1" 302 247 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:56 +0000] "GET /wp-admin/ HTTP/1.1" 302 402 "https://test.com/robots.txt" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:56 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.1" 400 314 "https://test.com/robots.txt" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:56 +0000] "GET /wp-sitemap.xml HTTP/1.1" 200 732 "https://test.com/sitemap.xml" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:56 +0000] "GET /sample-page/ HTTP/1.1" 200 57236 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:56 +0000] "GET /2022/08/01/hello-world/ HTTP/1.1" 200 60480 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:56 +0000] "GET /feed/ HTTP/1.1" 200 2030 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:56 +0000] "GET /comments/feed/ HTTP/1.1" 200 2013 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:57 +0000] "GET /wp-json/ HTTP/1.1" 200 161711 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:58 +0000] "GET /category/uncategorized/ HTTP/1.1" 404 62119 "https://test.com/2022/08/01/hello-world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"


Initially it visits valid pages, pulling the css and js files. It also uses a recent, valid-looking, user agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"

After that, it looks for elements on the site it can pass a POST request to. A great example of this is on forms. Here are a few POST requests targeting the comments and login pages. This is a WordPress site so it looks something like this:

192.1.a.a - - [14/Sep/2022:15:15:58 +0000] "POST /wp-comments-post.php HTTP/1.1" 200 2976 "https://test.com/2022/08/01/hello-world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:15:59 +0000] "POST /wp-login.php HTTP/1.1" 200 5902 "https://test.com/wp-login.php?reauth=1&redirect_to=https%3A%2F%2Ftest.com%2Fwp-admin%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"


Analyzing the POST requets we're able to see what they are passing. Below you see the user and password the application tries when trying to login:

2022-09-14 15:15:58 - 192.1.a.a {"comment":"","author":"ZAP","email":"foo-bar@example.com","url":"https:\/\/www.example.com","wp-comment-cookies-consent":"yes","submit":"Post Comment","comment_post_ID":"1","comment_parent":"0"}

2022-09-14 15:15:59 - 192.1.a.a {"log":"ZAP","pwd":"ZAP","rememberme":"forever","wp-submit":"Log In","redirect_to":"https:\/\/test.com\/wp-admin\/","testcookie":"1"}


It used the login name "ZAP", email foo-bar@example.com and the pwd "ZAP" for the wp-login form. If you have a WAF in place, looking for failed logins for the user ZAP might hint that the scanner is being used against your site.




2 - Web recon - multiple 404's

After the initial scan, it started scanning for different files and folders. It was looking for random PHP files, and .class files like this:

192.1.a.a - - [14/Sep/2022:15:16:03 +0000] "GET /5663358389285271028.php HTTP/1.1" 404 62411 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:16:03 +0000] "GET /2022/7199548016070754313 HTTP/1.1" 404 62119 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:16:03 +0000] "GET /2022/08/7268204792176218652 HTTP/1.1" 404 62119 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:16:04 +0000] "GET /2022/08/01/6427340488279210957 HTTP/1.1" 404 62119 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:16:05 +0000] "GET /category/8815925936762248407 HTTP/1.1" 404 62119 "https://test.com/2022/08/01/hello-world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:16:07 +0000] "GET /sample-page/feed/1340119542758152575 HTTP/1.1" 404 62119 "https://test.com/sample-page/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:18:26 +0000] "GET /WEB-INF/classes/0/98823529411765.class HTTP/1.1" 404 62119 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:18:27 +0000] "GET /WEB-INF/classes/0/71764705882353.class HTTP/1.1" 404 62119 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:18:27 +0000] "GET /WEB-INF/classes/0/25490196078431.class HTTP/1.1" 404 62119 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"


These queries lead to multiple 404's within a short period of time from the same IP address. Which brings up another great indicator to watch for, an IP performing an abnormally large number of queries against your web application.




3 - Vulnerability attempts (XSS, RCE, SQL Injections)

The basic reconnaissance was followed by checking if exploits would work against our forms. This makes sense, forms are a very easy vector for applications, they can contribute to XSS, SQLi and a variety of other application specific vulnerabilities. Here are a few of the POST requests we intercepted and their associated POST payloads:

{"comment":"c:\/Windows\/system.ini","author":"ZAP","email":"foo-bar@example.com","url":"https:\/\/www.example.com","wp-comment-cookies-consent":"yes","submit":"Post Comment","comment_post_ID":"1","comment_parent":"1"}
{"log":"c:\/Windows\/system.ini","pwd":"ZAP","rememberme":"forever","wp-submit":"Log In","redirect_to":"https:\/\/test.com\/wp-admin\/","testcookie":"1"}
{"log":"..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/Windows\/system.ini","pwd":"ZAP","rememberme":"forever","wp-submit":"Log In","redirect_to":"https:\/\/test.com\/wp-admin\/","testcookie":"1"}
{"comment":"..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/..\/Windows\/system.ini","author":"ZAP","email":"foo-bar@example.com","url":"https:\/\/www.example.com","wp-comment-cookies-consent":"yes","submit":"Post Comment","comment_post_ID":"1","comment_parent":"1"}
{"log":"..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\Windows\\system.ini","pwd":"ZAP","rememberme":"forever","wp-submit":"Log In","redirect_to":"https:\/\/test.com\/wp-admin\/","testcookie":"1"}
{"log":"\/etc\/passwd","pwd":"ZAP","rememberme":"forever","wp-submit":"Log In","redirect_to":"https:\/\/test.com\/wp-admin\/","testcookie":"1"}
{"log":"c:\/","pwd":"ZAP","rememberme":"forever","wp-submit":"Log In","redirect_to":"https:\/\/test.com\/wp-admin\/","testcookie":"1"}
{"log":"ZAP","pwd":"ZAP","rememberme":"forever","wp-submit":"Log In","redirect_to":"..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\Windows\\system.ini","testcookie":"1"}
{"user_login":"thishouldnotexistandhopefullyitwillnot","redirect_to":"","wp-submit":"Get New Password"}
{"comment":"http:\/\/www.google.com\/search?q=OWASP%20ZAP","author":"ZAP","email":"foo-bar@example.com","url":"https:\/\/www.example.com","wp-comment-cookies-consent":"yes","submit":"Post Comment","comment_post_ID":"1","comment_parent":"1"}


They didn't do much against our site, it was a Vanilla WordPress intance and pretty well insulated against these, but you can see the attempts to read system.ini or /etc/passwd. Each of these can be blocked by WAF technologies and via a log analysis tool you can flag multiple POSTs within a short time from the same location.

It also tried similar exploit attempts via the GET method:

192.1.a.a - - [14/Sep/2022:15:23:19 +0000] "GET /?p=1%22%26cat+%2Fetc%2Fpasswd%26%22 HTTP/1.1" 301 315 "https://test.com/2022/08/01/hello-world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:23:19 +0000] "GET /?p=1%26cat+%2Fetc%2Fpasswd%26 HTTP/1.1" 301 315 "https://test.com/2022/08/01/hello-world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:23:21 +0000] "GET /?p=1%22%7Ctype+%25SYSTEMROOT%25%5Cwin.ini HTTP/1.1" 301 315 "https://test.com/2022/08/01/hello-world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:23:28 +0000] "GET /?s=%27%7Ctype+%25SYSTEMROOT%25%5Cwin.ini HTTP/1.1" 200 50941 "https://test.com/category/uncategorized/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:23:31 +0000] "GET /2022/08/01/hello-world/?replytocom=1%3Bcat+%2Fetc%2Fpasswd%3B HTTP/1.1" 200 60525 "https://test.com/2022/08/01/hello-world/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:25:53 +0000] "GET /xmlrpc.php?rsd=any%0D%0ASet-cookie%3A+Tamper%3D2143452-165e-4e8a-8283-6a499b85e004%0D%0A HTTP/1.1" 200 991 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"


It also tried to access sensitive files (.htaccess) and some XSS attempts:

192.1.a.a - - [14/Sep/2022:15:26:35 +0000] "GET /search/.htaccess HTTP/1.1" 200 50844 "https://test.com/?s" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:26:35 +0000] "GET /search/feed/.htaccess HTTP/1.1" 200 50864 "https://test.com/?s" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:26:35 +0000] "GET /search/feed/rss2/.htaccess HTTP/1.1" 200 50884 "https://test.com/?s" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
192.1.a.a - - [14/Sep/2022:15:26:37 +0000] "GET /wp-includes/.htaccess HTTP/1.1" 403 463 "https://test.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0"
XSS:
192.1.a.a - - [14/Sep/2022:15:26:51 +0000] "GET /wp-login.php?action=%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1" 200 5569 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0"
192.1.a.a - - [14/Sep/2022:15:26:55 +0000] "GET /wp-login.php?action=javascript:alert(1) HTTP/1.1" 200 5569 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0"
192.1.a.a - - [14/Sep/2022:15:26:57 +0000] "GET /wp-login.php?action=%3Cimg%20src=%22random.gif%22%20onerror=alert(1)%3E HTTP/1.1" 200 5569 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0"
192.1.a.a - - [14/Sep/2022:15:29:03 +0000] "GET /?s=%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1" 200 51011 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0"
192.1.a.a - - [14/Sep/2022:15:29:38 +0000] "GET /?p=javascript:alert(1) HTTP/1.1" 301 321 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0"



All in all, the scanner didn't do anything specific to WordPress and didn't seem to have knowledge of the plugins or themes configured.

As a defender, it is good to be aware that out of the 10,000 requests, 980 of them generated a 404. They were trying to guess multiple files and directories and if you are monitoring your logs you can setup triggers to block requests (or alert) if you see multiple 404's from the same IP address.

Some of these logs are very suspicious and the SQL injections and RCE attempts can be flagged as well for an intrusion detection, WAF or log analysis tool.





Posted in   scanning_logs   siem     by trunc_team

Simple, affordable, log management and analysis.