How to Evade Detection: Hiding in the Registry April 7, 2019 https://www.tripwire.com/state-of-security/mitre-framework/evade-detection-hiding-registry/
But the thing is, even if it hides in the registry, it still can't run when it's blocked by AE/whitelisting, correct?
In regards to this: I wouldn't trust whatever you are using unless you tested it yourself. I instead use a HIPS rule to monitor any write activity to this and like reg. keys and startup directories.
My point is that they make a lot of fuzz about malware hiding in the registry, but malware still needs to execute to end up in memory. In other words, anti-exe will also block this.
Unless malware performed memory injection, hollow processing, etc. and modified the registry via API usage: https://docs.microsoft.com/en-us/windows/desktop/sysinfo/registry
Would need a bit more info on this, to understand how such an attack would work. The thing is, in order to hide in the registry, malware must still first be able to run. Only then they can modify the registry.
Here's the reference to all associated registry API's. Note that they can also be used via the listed shell functions: https://docs.microsoft.com/en-us/windows/desktop/sysinfo/registry-functions. Bottom line is that the registry can be modified programmatically as well as directly via apps like reg.exe.
To clarify, I wonder how such an attack would look like. So you run malware, it modifies the registry in a sneaky way, so now it will start even after reboot, if AV didn't detect it. But it still needs to run as a process, and malicious behavior should be detected by behavior blocker. Perhaps you can look for malware that uses this technique.
Take a look at the use of "debugger" in ref. to the registry. It allows another program to load as an alias of a legit program.
One of my favorite registry hiding malware persistence mechanisms is shells and their extensions. Here is a good article that is a bit dated but still applicable in regards to just how difficult it an be to detect some shell based malware: https://oalabs.openanalysis.net/201...e-hkey_current_user-shell-extension-handlers/ . I believe the issue mentioned in regards to Autoruns use in detection still exists. Every guide I have read recently on proper use of it warns that registry key data pertaining to shells must be fully enumerated to detect this kind of malware.
I forgot about that malware can also register DLL files in registry, but they should still always run as a separate process, no? Or can malware run as a single DLL file? This has never been clear to me.
/ Poweliks is one of the better examples of this: https://blog.trendmicro.com/trendla...e/poweliks-malware-hides-in-windows-registry/ -EDIT- Also, this one is interesting: https://www.microsoft.com/security/blog/2018/01/24/now-you-see-me-exposing-fileless-malware/ Whereas reflective .dll loading to inject into another processes memory is fairly well known and documented, reflective PE loading to do the same is not.
Another registry .dll sample is KHRAT. Note that the .dll file actually uses the .dat extension: https://unit42.paloaltonetworks.com/unit42-updated-khrat-malware-used-in-cambodia-attacks/
Here's another one. Override existing RDP use restrictions: https://0x00sec.org/t/anti-forensic-and-file-less-malware/10008
Yes, so basically it will always need some process to run in, like dllhost.exe or powershell.exe, that's the tricky part, if they hide in system processes.
