To name a few:
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.