This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject

NetWitness Community

  • Home
  • Products
    • NetWitness Platform
      • Advisories
      • Documentation
        • Platform Documentation
        • Known Issues
        • Security Fixes
        • Hardware Documentation
        • Threat Content
        • Unified Data Model
        • Videos
      • Downloads
      • Integrations
      • Knowledge Base
    • NetWitness Cloud SIEM
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Detect AI
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Investigator
    • NetWitness Orchestrator
      • Advisories
      • Documentation
      • Knowledge Base
      • Legacy NetWitness Orchestrator
        • Advisories
        • Documentation
  • Community
    • Blog
    • Discussions
    • Events
    • Idea Exchange
  • Support
    • Case Portal
      • Create New Case
      • View My Cases
      • View My Team's Cases
    • Community Support
      • Getting Started
      • News & Announcements
      • Community Support Forum
      • Community Support Articles
    • Product Life Cycle
    • Support Information
    • General Security Advisories
  • Training
    • Blog
    • Certification Program
    • Course Catalog
    • New Product Readiness
    • On-Demand Subscriptions
    • Student Resources
    • Upcoming Events
  • Technology Partners
  • Trust Center
Sign InRegister Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
NetWitness Community Blog
Subscribe to the official NetWitness Community blog for information about new product features, industry insights, best practices, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Announcement Banner

Scheduled Maintenance for the Case Portal during May 27-29

View Details
  • NetWitness Community
  • Blog
  • Detecting Sinkholed Domains With The X-Factor Parser

Detecting Sinkholed Domains With The X-Factor Parser

RSAAdmin
RSAAdmin Beginner
Beginner
Options
  • Subscribe to RSS Feed
  • Mark as New
  • Mark as Read
  • Bookmark
  • Subscribe
  • Email to a Friend
  • Printer Friendly Page
  • Report Inappropriate Content
‎2014-03-05 10:03 AM

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.

 

sinkholesession.JPG.jpg

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="&#x0d;&#x0a;" 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:

xfactor-results.JPG.jpg

 

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.

 

sinkholed-xstring.JPG.jpg
sinkholeddomains.JPG.jpg
sinkhole-xstring2.JPG.jpg

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.

 

xfactor-batman.JPG.jpg

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.

  • firstwatch
  • headers
  • Malware
  • NetWitness
  • NW
  • NWP
  • Parser
  • RSA NetWitness
  • RSA NetWitness Platform
  • security_analaytics
  • sinkhole
3 Likes
Share
1 Comment

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

  • Comment
Latest Articles
  • CVE-2022-1388: BIG-IP iControl REST RCE Vulnerability
  • Ragnar Locker Ransomware: The Rampage Continues…
  • Ransomware Email Attacks: Beware of BazarLoader
  • Detecting Impacket with Netwitness Endpoint
  • Exotic Lily: Global Activity Analysis
  • Threat Research Data Hygiene Exercise: Retirement of Threat Research Intelligence Content and Report...
  • Netwitness Orchestrator Dashboarding Overview
  • Highlights from Recent Releases - Here's What's New in NetWitness Platform 11.7 and 11.7.1
  • NetWitness News Bytes: Improved Broker Query Experience
  • NetWitness News Bytes: Meta Only Event Reconstruction
Labels
  • Announcements 52
  • Events 2
  • Features 9
  • Integrations 6
  • Resources 57
  • Tutorials 21
  • Use Cases 21
  • Videos 116
Powered by Khoros
  • Blog
  • Events
  • Discussions
  • Idea Exchange
  • Knowledge Base
  • Case Portal
  • Community Support
  • Product Life Cycle
  • Support Information
  • About the Community
  • Terms & Conditions
  • Privacy Statement
  • Acceptable Use Policy
  • Employee Login
© 2022 RSA Security LLC or its affiliates. All rights reserved.