App Review Malware Obfuscation Part 1

[Trident]

LUA from what I see (I do not use it at all so I haven’t researched) can be statically linked so you can create a fully portable executable with the LUA script in it.

Various obfuscations for the string can be used, from XOR, to replacing numbers with results of vectorised math.
We can go really creative here.

But again, it is an executable.

Not sure how different solutions will react to that, the ones that are aggressive towards low-trust executables (McAfee, Defender, Norton, Kaspersky and so on), and the ones that use aggressive static analysis and disassembling (Check Point, Deep Instinct), plus the ones that use emulation (CrowdStrike, Check Point, Palo Alto) won’t miss that.

Problem will be if additional tactics are applied as well (bloating and so on), but these will make distribution more difficult.

Some of the solutions above upload the full archives users download or save through email.

 

[bazang]

LUA doesn’t even come pre-installed (just like python), users will have to download the LUA runtime and install it manually and I guarantee 7/10 don’t even know what LUA is.

If the LUA is converted to an .exe, then the LUA interpreter (even a 'mini LUA interpreter') can be "packaged with the malicious LUA code converted to an .exe.

 

[Trident]

If the LUA is converted to an .exe, then the LUA interpreter (even a 'mini LUA interpreter') can be "packaged with the malicious LUA code converted to an .exe.

That's gonna create a more suspicious file as opposed to firing your Visual Studio or whatever you like using, and statically linking the runtime. The method you are describing is gonna create an executable that looks awfully like a packer + dropper (low trust, very little imports, abnormal .resource section), whilst if you go for the static linking, it is still a low-trust executable, but the script will likely go in the .rdata whilst the interpreter will be precompiled in the .text section.

LUA unlike python seems to allow very easy static linking.

Depending on how the lua environment behaves the way you are describing, if it is dropped in temp or loaded via reflective injection, it will be even more suspicious and unlikely to survive encounter with typical AVs.

 

[Andy Ful]

That's gonna create a more suspicious file as opposed to firing your Visual Studio or whatever you like using, and statically linking the runtime.

It is not so simple when LUA byte code is used:

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/redline-stealer-a-novel-approach/

Of course, any such methods can finally be well detected for the concrete interpreter. However, in the meantime, they can be a challenge for AVs/EDRs.

 

[LinuxFan58]

It is not so simple when LUA byte code is used:

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/redline-stealer-a-novel-approach/

View attachment 294997

Of course, any such methods can finally be well detected for the concrete interpreter. However, in the meantime, they can be a challenge for AVs/EDRs.

I did know about run time compilers like csc.exe. Did not know about compiler.exe. I will add it to the LolBins blocked by SRP for standard users.

 

[Andy Ful]

Here is some short info about automatic deobfuscation methods used in the past:

In parallel, automated deobfuscation has evolved into a sophisticated arms race. Early generic approaches relied on pattern matching or heuristics to locate VM structures (Rolles, 2009; Kinder, 2012; Guillot and Gazet, 2010; Sharif et al., 2009; Garba and Favaro, 2019). As obfuscation complexity increased, researchers adopted dynamic binary instrumentation and symbolic execution to simplify execution traces (Coogan et al., 2011; Raber, 2013; Yadegari and Debray, 2015; Yadegari et al., 2015; Salwan et al., 2018; Kalysch et al., 2017; Xu et al., 2018). To address the path explosion challenges (Banescu et al., 2016), synthesis-based methods such as Syntia (Blazytko et al., 2017), Xyntia (Menguy et al., 2021), and QSynth (David et al., 2020) were proposed to reconstruct instruction semantics by treating virtual handlers as black boxes. More recently, inference-based attacks have emerged: Li et al. (Li et al., 2022) proposed the Chosen-Instruction Attack (CIA) to infer mapping rules via input-output analysis, while Luo et al. (Luo et al., 2023) introduced interpreter semantics testing to reverse engineer obfuscated Lua bytecode. Furthermore, Zhang et al. (Zhang et al., 2025a) demonstrated that incorporating knowledge of VM diversification can significantly enhance the effectiveness of existing tools like Virtual-Deobfuscator, VMHunt and Syntia.

XuanJia: A Comprehensive Virtualization-Based Code Obfuscator for Binary Protection

 

[Trident]

I did know about run time compilers like csc.exe. Did not know about compiler.exe. I will add it to the LolBins blocked by SRP for standard users.

It comes with the executable/msi installer and the name, hash, everything can be different with every instance.

The McAfee report is very comprehensive.

The attackers use script compiled to bytecode.

 

[Andy Ful]

I did know about run time compilers like csc.exe. Did not know about compiler.exe. I will add it to the LolBins blocked by SRP for standard users.

The compiler.exe file is not a LOLBin; it can have different hashes and filenames. The csc.exe LOLBin is included in H_C.

 

[LinuxFan58]

@Trident and @Andy Ful

Thanks, I read that it writes files to UAC protected folders, so running standard user would prevent that I guess. It also uses msiexec a well known LolBin (also on the block list for standard user). Also I remember setting some GPO to prevent users to create scheduled tasks. Would that also raise an extra threshold?

 

[Trident]

@Trident and @Andy Ful

Thanks, I read that it writes files to UAC protected folders, so running standard user would prevent that I guess. Also I remember setting some GPO to prevent users to create scheduled tasks. Would that also raise an extra threshold?

This is one of the reasons why it may go unnoticed, it has a visible window and it writes to Program Files/Program Files (X86) mimicking a regular installer.

It even asks users to "spread the word", infecting more victims.

The attackers have abandoned typical practices (dropping in temp and so on) in favor of legit-like behavior and this is what makes it successful, not the LUA or the LUA bytecode itself.
That could have been achieved in many other ways as well.

 

[Andy Ful]

@Trident and @Andy Ful

Thanks, I read that it writes files to UAC protected folders, so running standard user would prevent that I guess. Also I remember setting some GPO to prevent users to create scheduled tasks. Would that also raise an extra threshold?

Using SUA is the general advice. However, most malware drops files in UserSpace, and there are many methods to get persistence. The most prevalent is via the RUN registry key (no process elevation). Of course, blocking the creation of scheduled tasks can help too. However, such restrictions can be inconvenient for many users and cannot cover all the numerous possibilities. It is better to prevent running such malware than trying to catch many possible ways of compromising the system. Using MD with MAX settings can be much more convenient than 100 policies.

 

[Trident]

Using SUA is the general advice. However, most malware drops files in UserSpace, and there are many methods to get persistence. The most prevalent is via the RUN registry key (no process elevation). Of course, blocking the creation of scheduled tasks can help too. However, such restrictions can be inconvenient for many users. It is better to prevent running such malware than trying to catch many possible ways of compromising the system.

My software Defender Hardening Console already includes an engine that scans scheduled tasks very aggressively with default-deny posture.

Anything that is not marked as trusted is suggested for removal and a privately tuned model is used to analyze scripts (when the LOLBin arg includes a path) or general command lines (when the malicious payload is running as an argument).

The Helios engine is equipped with the capabilities needed to clean up this attack.

 

[LinuxFan58]

Using SUA is the general advice. However, most malware drops files in UserSpace, and there are many methods to get persistence. The most prevalent is via the RUN registry key (no process elevation). Of course, blocking the creation of scheduled tasks can help too. However, such restrictions can be inconvenient for many users and cannot cover all the numerous possibilities. It is better to prevent running such malware than trying to catch many possible ways of compromising the system. Using MD with MAX settings can be much more convenient than 100 policies.

removed write access for standard users for sensitive registry keys in HKCU, which I could not protect with group policy. So long ago I forgot (also because I am using Linux now). I used the list of a freeware program which specialized in protecting (auto)run keys (forgot its name).

 

[Andy Ful]

Let's go back to the real world.

Although such samples as in the OP can happen, the chances of that are very, very small.
Such invasive attacks (one-click malware) are not so prevalent, probably less than 1% of malware in the wild, and usually can happen in targeted attacks. About 90% of malware can be prevented by good anti-phishing and anti-malware protection in the web browser. About 70% of one-click malware that could bypass web browser protection can be detected by AVs. So the chances of infections are roughly:

1/100 * 1/10 * 30/100 = 3/10000

There is no need to be paranoid about it.

Edit.
I included in calculations that such attacks must also bypass SmartScreen (by using a shortcut with LOLBin).

 

[Parkinsond]

robably less than 1% of malware in the wild

Makes sense; when trying to demo a scenario of MD breach, I will not use a prevalent malware representing 80% of the "in-the-wild".

 

[Jonny Quest]

Makes sense; when trying to demo a scenario of MD breach, I will not use a prevalent malware representing 80% of the "in-the-wild".

I agree, scenarios like these are usually extreme situations, extreme malware, extreme samples, most of us will never run into or experience in our daily lives.
But, it makes for great debate

 

[Andy Ful]

Makes sense; when trying to demo a scenario of MD breach, I will not use a prevalent malware representing 80% of the "in-the-wild".

The "demo" was also prepared to bypass SmartScreen (the MotW was removed from files). However, even with MotW, the shortcut can be prepared to bypass SmartScreen in the attack. That is why such attacks gained some popularity.
The video cannot be taken as a real-world attack, but rather as a part of it, focused strictly on bypassing the AV detection engines. I used a quite similar scenario in my series on "AV challenge".

 

[Parkinsond]

shortcut can be prepared to bypass SmartScreen in the attack

The safest way to deal with shortcuts is to block LNK with SRP.
If I let LNK to launch, it will depend on the chance of blocking the consequent files by the available tools, which might not be good all the time.

 

[Parkinsond]

But, it makes for great debate

If debate is "decent", it is more than welcome; good debate creates good knwoledge.

 

[rashmi]

Panic erupted when @cruelsister's "BEAR" bomb went off... Everyone's frantically searching for the defuse button—PAWS the unBEARable chaos... HUG COMODO!