You are browsing the archive for Preaching.

the art of staying ghidrated

March 10, 2019 in Preaching, Random ideas

Last few days were very exciting. The NSA folks released ghidra – a killer reversing app they use internally.

The software is great; I played with it for a bit, and like many other reversers shared some screenshots, and comments on Twitter. Over last few days I looked through many Twitter and blog posts referencing the tool, and it’s pretty obvious this is going to be a gamechanger.

It’s free, it’s feature-rich, it’s expandable, and it warms our heart every time it shows us cute ‘dragonian’ animations. And speaking of ‘draconian’, there is a lot of negative sentiment about eligibility rules, and a price tag that prevent non-corporate users from purchasing IDA License.

Having to choose free vs. unreachable, the choice is pretty obvious.

There is one thing though that I don’t see covered in posts that are focused on this exciting new toy. It is the mission.

(For the record, I am going to wear my tinfoil hat now.)

When it comes to a mission, organizations like NSA always have one. It is somehow bizarre that government orgs known for their secrecy release tools that are giving them an edge. GCHQ releases a CyberChef, NSA releases Ghidra. Should we expect more tools ? Released by DGSE, BND, and others?

The reason I am saying they are giving the respective orgs an edge is because these orgs rely on reversing a lot. They can obviously purchase exploits from brokers, intel from vendors, or access source code by any means necessary, but ultimately, they do have a special task group that is responsible for cracking stuff en masse. And ghidra’s architecture supporting collaboration makes a good case for a circumstantial evidence to support my hypothesis here.

I am curious what is the mission when it comes to ghidra. Only a fool would believe that a release like this is just for ‘the good of the <input your preferred good reason here>’.

I believe both CyberChef and Ghidra support missions that are pretty obvious:

  • PR – we are not that bad; we share with community; we advance the science of security/reversing/etc.
  • Recruitment – kinda PR-related, but if the goal is to find geek recruits who want to work at the respective agencies then this works pretty well; these are excellent, mature tools, youngsters can use them, learn from them (for free!), and eventually become experts in using them; at that stage they can enter the respective agency, and immediately jump on solving problems, saving lots of training time (in a similar manner large companies sponsoring labs at school train students to use the ‘sponsored’ tools which they will surely prefer to stick to, and purchase when they become decision makers in the future)

The other motives are not clear.

One that comes to my mind is an easy access to products of work of reversers who will surely jump on an occasion to add plugins, support new file formats, firmware modules, possibly in areas that are less mainstream.

Will such input create a snowball effect and give the agency access to resources that will improve the efficiency and reach of the tool, especially its internal version not shared with public?

I don’t think this is a very good mission per se, but I can easily imagine release being a product of someone’s annual objective to ‘enhance ghidra capability to e.g. triple number of supported firmware modules’. Open sourcing the software could be one attempt to achieve this objective with a minimal input, maybe a bit of social media manipulation could steer people towards cracking problems interesting from agency’s perspective?

Hard to say. Again, I don’t buy this idea of a mission too much, because management and quality check of such crowd-sourced code would probably require more work than actually writing your own modules, or gaining access to the source code.

I do describe the above mission for a reason tho. Because even if it is not a true mission, it may end up being one. And it leads to a question, and that is one that non-US reversers need to ask themselves. Will your work become a building block in enhancing the capabilities of the US foreign agency? Could it be that one day your parser, dumper, plug-in will allow that foreign agency to faster crack software of the router at your country’s ISP, or your IoT toys? One may argue that all our public research can serve such role, and it’s a fair point, but the important distinction is that by contributing to ghidra there is that direct link to the agency that makes the action a conscious decision, and may be seen as a direct contribution.

This is an open question. This is also non-judgmental question. It is potentially a legal question tho. And perhaps a moral one too.

The story of an underTAG that tried to wear a mitre…

March 10, 2019 in Mitre Att&ck, Preaching, Random ideas, Sysmon, threat hunting

Today we tag everything with Mitre Techniques. I like it, but I would also want a bit more flexibility. So, I like to mix the ‘proper’ Mitre tags with my own tags (not only subtechnique tags, but also my own specific tags).


Say… you detect that System.Management.Automation.dll or is loaded into a process. Does it mean it is T1086: PowerShell? Or does it mean, that the process is using a DLL that offers automation capabilities? And may not even do anything dodgy? I suspect (s/suspect/know/) that calling it T1086: PowerShell w/o providing that extra info loses a lot of context.

Why not calling it what it is? <some magic prefix>: Powershell Automation DLL?

Is loading WinSCard.dll always an instance of T1098: Account Manipulation, or T1003: Credential Dumping? Or is it just a DLL that _may_ be used for nefarious purposes, but most of the time it is not (lots of legitimate processes use it; sysmon logs analysis is a nice eye opener here).

Why not calling it <some magic prefix>: Smart Card API DLL?

As usual, at the end of this tagged event, or events’ cluster, there is a poor soul, and the underdog of this story that is tasked with analysing it. If our tagging is as conservative as the mindset of politicians who studied at Eton… then so will be the quality of analysis, statistics, and actual response.

And it is easy to imagine confusion of analysts seeing events tagged with a vague name. For example, net.exe command that accesses user/account data, and the loading of WinSCard.dll may make them assume that there is a cluster of ‘account manipulation’ events indicating an attack. A triage of such vague cluster of events is a time wasted… There is a response cost, and there is an opportunity cost at play here. The example is over-simplistic of course, but the devil is in the details. Especially for the analysts.

I’d say… given the way most of events are logged today, often w/o much correlation and data enrichment at source, the event collection process should make any attempt possible to contextualize every single event as much as possible.

We can argue that combining data at its destination, in aggregation systems, SIEMs, collectors, or even ticketing systems, or on a way to them, is possible and actually, desirable… today’s reality is that we need that single event to provide as many answers as possible…

This is because we know that Data Enrichment at the destination is a serious pain in the neck and relies heavily on a lot of dependencies (up to date asset inventories, list of employees, DHCP mapping, then there is a lack or poor support of nested queries, poor performance of nested queries, and this forces us to use a lot of lookup tables that need to be up to date and require a lot maintenance). And if we need to go back to the system that generated event to fetch additional artifacts, or enrich data manually, then we are probably still stuck in a triage process A.D. 2010…

So… if we must tag stuff, let’s make it work for us, our analysts, and make it act as a true data enrichment tool that it was meant to be… If the event, their cluster, or detection based on them is not actionable, then it’s… noise.