Regin, the top-tier PASSIVE_LEVEL malware!

Over the past few weeks it seems left and right there's Regin this, Regin that. I am not going to do a detailed analysis and discuss its stages and what have you, as there are various/informative in-depth whitepapers, etc.

To name a few:

Symantec, Symantec.
Kaspersky, Kaspersky.
F-Secure.

In my opinion, Regin is your typical malware that expands outside of the reverse engineer/security community due to its original goal. Journalists or researchers with little kernel-level knowledge/background get a hold of it and before you know it, it's the next biggest sophisticated piece of malware and all that matters is PR. At this point, writing accurate and detailed articles doesn't matter anymore. What am I referring to, and what will I instead talk about with Regin?

Secret Malware in European Union Attack Linked to U.S. and British Intelligence.

Let's quickly talk about a short few things the whitepapers haven't mentioned (as far as I am aware), and the above article. Respectfully, I have absolutely no idea who reviewed the above article before it was pushed. You have to wonder if The Intercept rushed like hell to publish this article because Symantec released their whitepaper and didn't care about what half of it even said. Note the dates:

There's a lot of strange and irrelevant information in that article you can pick at, but the absolute best is:

This Regin driver recurrently checks that the current IRQL (Interrupt Request Level) is set to PASSIVE_LEVEL using the KeGetCurrentIrql() function in many parts of the code, probably in order to operate as silently as possible and to prevent possible IRQL confusion. This technique is another example of the level of precaution the developers took while designing this malware framework.

Since its publication date this has yet to have been changed, so I guess they don't care after all about its inaccuracies. Anyway, if it's not a surprise, calling KeGetCurrentIrql over and over again throughout the code is just a PAGED_CODE macro. It has absolutely nothing to do with stealth, and PASSIVE_LEVEL doesn't automatically imply obfuscation or stealth. For an example, here's an excerpt from db405ad775ac887a337b02ea8b07fddc (kernel driver - stage 1).

 call  KeGetCurrentIrql  
 test  al, al  
 jnz   short loc_FDEFAA3D  
 push  dword ptr [esi] ; Handle  
 call  ZwClose  
 test  eax, eax  
 jnz   short loc_FDEFAA3D  
 push  18h  
 push  ebx  
 push  esi  
 call  sub_FDEFA2EC  
 add   esp, 0Ch  
 mov   bl, 1  

Again taking a look at db405ad775ac887a337b02ea8b07fddc, there's another interesting tidbit throughout the code:

 push  43726150h 
 push  20h  
 push  edi  
 call  ds:ExAllocatePoolWithTag  

The above is the kernel mode driver's pool tag, the # of bytes to allocate for the memory request, the pool type, and finally its call to ExAllocatePoolWithTag allocate pool memory. Okay, so what's the big deal? If we convert the pool tag operand to a character, we get the following result:

 push  'CraP'  
 push  20h  
 push  edi  
 call  ds:ExAllocatePoolWithTag  

The pooltag is CraP : ) This is probably how many of us feel about this malware being so hyped by the media. There are of course others throughout the code, for example:

 push  'CraP'  
 push  eax  
 push  1  
 call  ds:ExAllocatePoolWithTag  

Overall, I guess the moral is to take time to get as much accurate information as you can for your articles. I cannot speak for anyone but myself, but as someone with a love for reverse engineering, malware, and debugging, I appreciate in-depth whitepapers and articles that provide thorough analysis. If all you're worried about is competition for views and hyping malware, chances are you're not going to appeal to the people who really care about the written content.

PS: Thanks to KernelMode as always for the hilarious discussion.