Category Archives: Threat Hunting

Threat Hunting – localization issues

Posted on by

So you finished writing your perfect threat hunting query.

Done and dusted, right?

Hmm, sorry… chances are, it is… broken.

How come?

One reason, but it has many acronyms: L10N, T9N, I18N or G11N.

If you are mostly dealing with English-centric versions of the operating systems you may now stop reading. But… You will be missing out.

Why?

THERE ARE OTHER LANGUAGES OUT THERE. And they come with a luggage…

The acronyms listed earlier expand into:

  • Translation (T9N)
  • Localization (L10N)
  • Internationalization (I18N)
  • Globalization (G11N) 

They define a different world. The world that is quite esoteric to monoglots. The world that embraces the world of ‘other languages in use’. The whole lot of new devices ‘suddenly in scope’, too. The world of foreigners who do not use English as their MAIN language. Most of Europe really. Many places in the world, REALLY!

In this world, your c:\Program Files becomes… an item from this table.

Pfff… and suddenly, all your queries relying on hard-coded ‘program files’ string need to be adjusted.

You are welcome! 🙂

And it’s not the only artifact that changes.

What about ‘New folder”? This thread shows some examples of “New Folder” string represented in various languages:

  • Neuer Ordner
  • New folder
  • Nouveau dossier
  • Nova Pasta
  • Nowy folder
  • Nuova Cartella

And again, this is just one of many ‘not so subtle’ localization changes to the OS that affects the way you should be writing your threat hunting queries or doing your DFIR engagement. And yes, it complicates things A LOT. And yes, Hebrew, Arabic, Chinese and Japanese versions of these do exist as well, and they complicate things even more.

Where does it leave us?

Simple answer: pay attention. More responsible answer: explore the environment & adjust queries as per need.

As long as your results generating framework/language supports Unicode you should be seeing these localized “things”, but only IF YOU EXPECT THEM. Once you see them, bundle them together and use them as a template, f.ex. use combos like this for a c:\program files folder name:

"\Program Files",
"\Programme",
"\Archivos de programa",
"\Programmes",
"\Programmi",
"\Arquivos de Programas",
"\Programmer",
"\Programfiler",
"\Fisiere Program"

These are not all the possibilities, of course, but they are good enough to make us all ‘aware’.

Going forward, we will all be localizing our queries. Oui?

Event ID 7039 – out…pid a pid

Posted on by

This event is not very well explained on the internet, so I took a liberty of describing it below:

The event message is as follows:

A service process other than the one launched by the Service Control Manager connected when starting the [SERVICE_NAME] service. The Service Control Manager launched process [PID1] and process [PID2] connected instead.

Note that if this service is configured to start under a debugger, this behavior is expected.

The message kinda tells us what happened – two different processes talk to SCM instead of one. It doesn’t really tell us WHY this happens.

Example from a case I looked at in response to a query on Twitter:

In this particular case the c:\windows\sysmon.exe was registered as a program that service process starts from. I believe this file was later manually replaced with a newer version of sysmon.exe. The little-known fact about distributable version of Sysmon (sysmon.exe from the sysinternals page) is that it is built as a 32-bit executable with an embedded 64-bit executable inside its resources. When launched on a 64-bit system the 32-bit version extracts and spawns that 64-bit version executable (note the PIDs and compare them against the Event Log):

Looking at it in general terms: when you register a service its configuration in Registry points to an executable file. This executable is then used to launch a service. Some services are not designed in a very good way. Once such programs are launched as a service, they spawn other processes, sometimes even batch files that may as well launch other programs. If one of these spawn programs talks to SCM the latter immediately recognizes that it’s not the same executable as the service process the service configuration points to. Such design is in general poor and could be a subject to possible privilege escalation (in a lolbinish way). And since this is a security concern the event 7039 is being logged.

And this leads me to the key reason I wanted to write an article. The Event 7309 tells you two things:

  • Whoever designed the service didn’t do the best job, OR, more importantly,
  • A bad guy may be using a badly designed service to escalate privileges.

Hence, you should be looking at these.

And last, but not least – does it mean Sysmon is designed badly? Nope. It’s designed in a clever way to use a single portable executable for 32-bit and 64-bit systems. The problem arises from a corner case in a way it was manually upgraded, instead of using the “-u” switch.