Playing hide and seek catch – with fileless malware.

Malicious code… – it gets everywhere…

It’s a bit like a gas, which will always fill the space it finds itself in – only different: it will always get through ‘holes’ (vulnerabilities) in a computer system. So our job (rather – one of them) is to find such holes and bung them up. Our goal is to do this proactively; that is, before malware has discovered them yet. And if it does find holes – we’re waiting, ready to zap it.

In fact it’s proactive protection and the ability to foresee the actions of attackers and create a barrier in advance that distinguishes genuinely excellent, hi-tech cybersecurity from marketing BS.

Here today I want to tell you about another way our proactive protection secures against yet another, particularly crafty kind of malware. Yes, I want to tell you about something called fileless (aka – bodiless) malicious code – a dangerous breed of ghost-malware that’s learned to use architectural drawbacks in Windows to infect computers. And also about our patented technology that fights this particular cyber-disease. And I’ll do so just as you like it: complex things explained simply, in the light, gripping manner of a cyber-thriller with elements of suspense ).

First off, what does fileless mean?

Well, fileless code, once it’s gotten inside a computer system, doesn’t create copies of itself in the form of files on disk – thereby avoiding detection by traditional methods, for example with an antivirus monitor.

So, how does such ‘ghost malware’ exist inside a system? Actually, it resides in the memory of trusted processes! Oh yes. Oh eek.

In Windows (actually, not only Windows), there has always existed the ability to execute dynamic code, which, in particular, is used for just-in-time compilation; that is, turning program code into machine code not straight away, but as and when it may be needed. This approach increases the execution speed for some applications. And to support this functionality Windows allows applications to place code into the process memory (or even into other trusted process memory) and execute it.

Hardly a great idea from the security standpoint, but what can you do? It’s how millions of applications written in Java, .NET, PHP, Python and other languages and for other platforms have been working for decades.

Predictably, the cyberbaddies took advantage of the ability to use dynamic code, inventing various methods to abuse it. And one of the most convenient and therefore widespread methods they use is something called reflective PE injection. A what?! Let me explain (it is, actually, rather interesting, so do please bear with me:)…

Launching an application by clicking on its icon – fairly simple and straightforward, right? It does look simple, but actually, under the hood, there’s all sorts goes on: a system loader is called up, which takes the respective file from disk, loads it into memory and executes it. And this standard process is controlled by antivirus monitors, which check the application’s security on the fly.

Now, when there’s a ‘reflection’, code is loaded bypassing the system loader (and thus also bypassing the antivirus monitor). The code is placed directly into the memory of a trusted process, creating a ‘reflection’ of the original executable module. Such reflection can be executed as a real module loaded by a standard method, but it isn’t registered in the list of modules and, as mentioned above, it doesn’t have a file on disk.

What’s more, unlike other techniques for injecting code (for example, via shellcode), a reflection injection allows to create functionally advanced code in high-level programming languages and standard development frameworks with hardly any limitations. So what you get is: (i) no files, (ii) concealment behind trusted process, (iii) invisibility to traditional protective technologies, and (iv) a free hand to cause some havoc.

So naturally, reflected injections were a mega-hit with developers of malicious code: At first they appeared in exploit packs, then cyber-spies got in on the game (for example, Lazarus and Turla), then advanced cybercriminals (as it’s a useful and legitimate way of executing complex code!), then petty cybercriminals.

Now, on the other side of the barricades, finding such a fileless infection is no walk in the cyber-park. So it’s no wonder really that most cybersecurity brands aren’t too hot at it. Some can hardly do it at all.

Our ‘paradigm’ of multi-level protection has this threat covered by various technologies, which control all stages and vectors of attack: behavioral analysis, special checks for critical areas, automatic protection against exploits. But the main thing here: our patented (US 10691800, RU 2665910, RU 2659738) technologies for analysis of memory for uncovering suspicious activity that can be used by fileless malware.

Example: our System Watcher (that proactively protected users against WannaCry and other cyberattacks), which constantly monitors activity of applications on a computer, finds a certain trusted process executing unusual or security-critical actions. In this case we look at the event very carefully, in particular finding out in which memory addresses the code that caused the event is located. If we see a suspicious address – we analyze it deeper to see if there’s any reflected code present. Thus, we don’t look for a needle in a haystack – blindly plowing through the whole of the memory, and instead conduct deliberative targeted analysis of suspicious addresses in line with a set of rules. And that’s how we quickly, reliably uncover the crafty little so-and-so called fileless malware.