This is a follow-up to a prior post on detecting sinkholed domains here. Some domains that have been sinkholed by anti-malware organizations can be identified by reading the Server’s X-String Variable in the Header.
Security Analytics does not extract this X-String as meta. A parser would need to be written to extract this automatically. However, the parser wouldn’t need to be so specific to extract just X-Strings for Sinkholes. What else might be hiding within the X-Strings on these servers? Would other malware command and control strings be embedded in X-Strings? The parser would need to extract all X-Strings as meta so they can be reviewed and reported against.
This is what the parser looks like:
<?xml version="1.0" encoding="utf-8"?>
<parsers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="parsers.xsd">
<parser name="X Factor Detect" desc="This extracts the string from the x- HTTP Headers">
<declaration>
<token name="tXfactor" value="X-" options="linestart" />
<number name="vPosition" scope="stream" />
<string name="vXfactor" scope="stream" />
<meta name="meta" key="xfactor" format="Text" />
</declaration>
<match name="tXfactor">
<find name="vPosition" value="
" length="512">
<read name="vXfactor" length="$vPosition">
<register name="meta" value="$vXfactor" />
</read>
</find>
</match>
</parser>
</parsers>
Starting in the declarations section, I define my primary token I want to use to pull out the X-String variables, which is “X-“ at the beginning of the line. I define a variable position, a variable Xfactor, and reference a new meta key that I will be dumping all of my results into. (When I write parsers, I like to denote tokens and variables by prepending lowercase “t” and “v” to my values to help me keep my logic straight.)
Next comes my match statement. So whenever this parser finds “X-“ at the beginning of the line, it will then search for a variable number of spaces up to 0D 0A (the carriage return in hex) or up to 512 spaces, whichever comes first. It will then read whatever occupies that space as the “vXfactor” which should be a string of text and will register it as meta in my new Index Key of “xfactor”
This is what the results look like:
A simple capture rule to detect when “xfactor contains sinkhole” can now be created to alert on my primary use case, which was to detect sinkholes.
My secondary use case was to find any possible c2 commands in the X-Strings, however, at the time of this writing, none have been detected. However, there are some interesting anomalies I have found, such as references to comic book characters and solicitations to hire “hackers” and web developers.
Other use cases for a parser like this would be passive vulnerability detection and notification. As an example, in the results graphic above, you can see lots of different PHP versions. If this parser were deployed in a web hosting environment, it could detect which hosts were using outdated versions of PHP, ASP and other web applications that advertise versions within their X-Strings.
This parser is presented above as an educational lesson on the power of the parsing language. It is presented as-is and without warranty. If you choose to deploy this, it is at your own risk.
1 Comment
