This post is the first in a series of network activity reviews using Splunk to identify threat actors around the world attempting to exploit our network vulnerabilities. From past analysis, the type of scans and the targeted vulnerabilities change on daily basis, showing a very dynamic and determined effort in finding and exploiting vulnerable sites and admins oversights.

Here is a review of Snort events captured during the last 24 hours (using the Firegen for Snort Splunk App):

Firegen for Snort Splunk App

Firegen for Snort Splunk App Summary Dashboard

Snort recorded 155 events from 73 different sources, with some peaks around 5 am and 7:30 am. Only the traffic that goes past the firewall is analyzed by Snort. Let’s take a look at the top offenders.

The first on the list of IP addresses that triggered Snort alerts is, an IP that seems to originate from Netherlands. Snort recorded 19 events matching the following 5 signatures:

ET WEB_SERVER Possible SQL Injection Attempt SELECT FROM (1:2006445)
SQL 1 = 1 – possible sql injection attempt (1:19439)
ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT (1:2006446)
ET WEB_SERVER Possible Attempt to Get SQL Server Version in URI using SELECT VERSION (1:2011037)
ET WEB_SERVER MYSQL Benchmark Command in URI to Consume Server Resources (1:2011041)

Typically, when Snort indicates a possible SQL injection attempt one can confirm from the website logs that indeed such an attack was attempted. These attacks were directed at an IIS website. Using Splunk to lookup the relevant searches:

index=”iis” c_ip= | iplocation c_ip
| table _time,host, c_ip, cs_uri_stem,cs_uri_query,Country,sc_status,cs_User_Agent

reveals a long list of SQL injection attempts:

List of http requests

HTTP requests from

Some examples of web requests:,2)=(select*from(select%20name_const(CHAR(111,108,111,108,111,115,104,101,114),1),name_const(CHAR(111,108,111,108,111,115,104,101,114),1))a)%20–%20%22x%22=%22x

Replacing the encoding of %20 and %22 with the actual characters, the SQL injection part attached to the legit HTTP GET parameters (eventid=36888&source=Schannel) would translate to:

” or (1,2)=(select*from(select name_const(CHAR(111,108,111,108,111,115,104,101,114),1),name_const(CHAR(111,108,111,108,111,115,104,101,114),1))a) — “x”=”

The use of name_const function indicate that this was targeted at MySQL. From the start this indicates that it was from a generic scanning tool because a hacker that would specifically target this site would have no problem identifying the fact that is using MS SQL and not MySQL.

The CHAR(111,108,111,108,111,115,104,101,114) statement is equivalent to: ololosher (Ololosher seems to be a Slavic name). Replacing the CHAR statements we get:

” or (1,2)=(select*from(select name_const(‘ololosher’,1),name_const(‘ololosher’,1)a) — “x”=”x

name_const(‘ololosher’,1) simply returns a column called “ololosher” with the value of 1 while name_const(‘ololosher’,1)a returns a column called “a” with the value of 1. It seems that the purpose of these SQL commands is just to determine if the target is susceptible to SQL injection attacks, being a component of the discover phase of a typical attack.

Searching the logs for similar HTTP queries for the last 7 days returns 19 different IP addresses from countries like China, Vietnam, Brazil, US, Romania, etc. the usual suspects, all trying the same query, obviously using the same tool. A 30 days query returns 69 addresses.

The second IP on the list is from Germany with 16 suspicious connections.  Snort identified the following signatures:

SERVER-APACHE Apache Struts remote code execution attempt (1:41818)
ET WEB_SERVER CURL Command Specifying Output in HTTP Headers (1:2019308)
SERVER-APACHE Apache Struts remote code execution attempt (1:41819)
ET WEB_SPECIFIC_APPS Possible Apache Struts OGNL Expression Injection (CVE-2017-5638) M2 (1:2024044)
ET WEB_SERVER Possible bash shell piped to dev tcp Inbound to WebServer (1:2019285)

The IP was not recorded in any of the website logs, while the firewall did indicate that it reached the IP address hosting the actual website. Firegen Palo Alto Analyzer for Splunk shows 4 http connections:

Firegen for Palo Alto Splunk App

Traffic generated by

This means that the requests were sent to an IP address and not a host name. There is no website configured to answer to the IP address itself, just to queries that specify a host name, i.e. is resolves to but browsing to will not bring up

The third IP on the list is coming from France. There were 12 suspicious connections using 4 attack signatures recorded by Snort:

ET WEB_SERVER PHP tags in HTTP POST (1:2011768)
ET SCAN Suspicious User-Agent inbound (bot) (1:2008228)
BLACKLIST User-Agent known malicious user agent BOT/0.1 (1:21925)
ET SCAN JCE Joomla Scanner (1:2016032)

Looking up the IIS logs through our Firegen IIS Analysis for Splunk we can see the following type of requests:

/admin/Cms_Wysiwyg/directive/ forwarded=true&isIframe=true&___directiv

None of these files exist on the attacked website, and the threat actor was obviously looking for vulnerabilities in an old JCE (Joomla Content Editor). The wawalo.gif is a fake image that is used in these type of attacks. wawalo.gif was in fact a PHP file. Once uploaded as an image (bypassing the faulty security checks), the hackers would rename it as wawalo.php and use it to compromise the site hosting Joomla CRM.

The 4th IP, from Germany, exhibits a behavior almost identical with the one before, looking for the same type of vulnerabilities.

So, what is the meaning of all these? Well, there are a few things that we can use. The hackers will always probe for SQL injection vulnerabilities, using a variety of obfuscated statements meant to confuse detection controls. Make sure that your websites are validating every input and follow recommended practices. Do not rely on security by obscurity or think that a site is too small to get noticed. These are hacking tools that scan entire ranges of IP addresses and they don’t discriminate. Older vulnerabilities that received a wide media exposure (such as the Apache Struts that affected Equifax) are still probed, and chances are that many websites are still vulnerable. It is a matter of time before they get compromised.