Cracking Zeppelin

A few days ago Brian Krebs published a piece about Zeppelin key cracking, so … since I was also involved in recovering files for some of the ransomware gang victims I thought I will add a few cents…

Back in 2020, I was approached by one of my clients to have a quick look at this particular piece of Zeppelin ransomware sample; and as you can imagine, I was immediately skeptical — it’s really unlikely to crack crypto of modern ransomware so I pretty much threw a towel, immediately, kinda by default.

BUT…

I was also aware of work of Lance Jones, and his UNIT221B on this particular malware strain and… that offered some hope…

I decided to try to factor these keys myself and what followed was a VERY intense week where I had to very quickly learn how to use and pay for AWS, how to allocate its resources, how to fix lots of other peoples’ bugs in a software that was — by that time — full of legacy assumptions, and – for the lack of a better word — in a need of a lot of troubleshooting and ‘code massaging’.

But the rewards were there, waiting…

The morning I saw the first cracked key I became ecstatic. I didn’t care about money this was earning me, I didn’t care what a bill I had to pay to AWS, here I was, breaking the damn ransomware! We were able to recover files for the client. Just like that!

Working in a cybersecurity space can be quite daunting, we often see ‘bad’ things, we live ‘failure’ every day. Yet, that moment I managed to crack the first key was a moment of triumph. Not all is lost. We are actually helping. We matter. it’s cheesy as hell, but there is no better satisfaction than disrupting the bad, for good.

And … it did happen again, I’ve spent a lot of time cracking other keys, but we did beat them. For a cost of a few hundred dollars on AWS, each time, we did beat them, every single time.

Beyond good ol’ Run key, Part 139

This one is a curious one. I actually don’t know how to trigger it!

Yet, I will document some bits and bobs, so that you may take these entry points into consideration, at least from a DFIR perspective.

So, edgehtml.dll and mshtml.dll are monsters of a library (23-25MB+). One of the things they do is they provide functions that work in so-called Diagnostic Mode. When Browser is in that mode, it checks a number of environment variables, and if they are set, it will load a COM library specified by one of these entries (JS_DM_CLSID).

And all these Java Script/Diagnostic Mode environment variables it checks are:

  • JS_DM_CLSID
  • JS_DM_FLAGS
  • JS_DM_PATH
  • JS_DM_ID

I know it’s not a lot, but if JS_DM_CLSID is set as an environmental variable, you better check it’s value as it may be loaded by the browser. If you know more about the Diagnostic Mode, please let me know.