Discussion in 'other anti-virus software' started by victor43, Jun 15, 2017.
Can modern day AV Scanners scan for viruses in RAM on computers running Windows 7/8/8.1/10 ?
Good question. Fileless malware resides in memory only until the next reboot.
Damage that it inflicts can't be monitored, written to a log and retrieved for analysis later.
Usually on demand scans do but realtime monitors not (they usually scan file when it's accessed on HDD).
Thanks for the reply. But how can kernel mode AV Scanners scan user mode or kernel mode space belonging to another process ? I thought that it was risky to do that and risk BSOD ?
The problem is when malware disguises itself as a legitimate Windows running process, it can evade detection and containment by security software.
There is no good fix for the problem.
I would say most of the major AV vendors have real-time memory scanners but they are limited in scope detection capabilities. They are post-execution detection such as Eset's advanced memory scanner meaning some infection might have occured. Also they are looking for a signature; full or generic. Most will try to block the malicious process behavior using known memory attacks such as code injection, hooking, etc..
Sorry, I don't know technical answer to that. Most on demand scanners I use have an option to scan memory and they usually show processes and loaded libraries being scanned.
Some AV vendors like Eset load their driver "stubs" into the kernel root table. This does not permit them to scan kernel space but allows their drivers kernel code properties to examine user mode applications. It also gives those driver stubs kernel mode protection against malware.
Are you saying that user mode applications loaded and executing in RAM can be scanned by AV Scanners then but not kernel mode applications or modules residing in RAM ?
For example, AV scanners can monitor the installation of kernel mode drivers. They can monitor any driver loaded into the kernel. They cannot monitor kernel mode driver execution once loaded into the kernel for 64 bit OSes. Windows PatchGuard protection prevents that.
32 bit OSes do not have PatchGuard protection. So some security software of old, namely HIPS's, could monitor kernel mode code execution.
Additionally, all application code including AV software runs at level 1, user mode. The only application code allowed to run at level 0, kernel mode, are specially signed kernel mode drivers. There is one exception in Win 10. MS developed the ELAM interface that Windows Defender and a few AV vendors utilize that allows them to load their associated AV kernel process with level 0 characteristics. This is for protection purposes only for the AV kernel program. The program itself runs as a level 1, user mode process .
Oh I see, thanks for the in depth and informative response. I would like to point out that I have a read an article where Windows PG can be disabled by malware. I would like to clarify one thing and that is that you say kernel mode driver execution cannot be monitored so once a kernel mode application is finished loading and executing it is not possible to monitor it yes ? This last question refers to all OS kernel code and at the same time all other (non OS) kernel mode applications. So once code (any mode kernel or user) is executing it is not possible to read from the memory from which this code occupies ?
For reference - not the best for technical details but gets the point across: https://en.wikipedia.org/wiki/Kernel_Patch_Protection
In regards to your conerns:
A general brief OS review. The Windows x64 OS consists of two areas; user space where applications reside and kernel space where the OS kernel, ntoskrn.exe i.e. system, "the holy of holies" reside along with other various storage and control areas such as the kernel root table. The kernel root table contains various tables such as knowndlls(for x64 .dlls) and knowndlls32) for x86 .dlls. These are the common system .dlls that will load into every running process. It is these kernel storage and control areas that can be attacked with limited success by malware and AV software has limited success in stopping. That stopping is usually in the form of blocking activity against where the source data loaded into these areas are stored such as the registry.
The bottom line - a true exploit of ntoskrnl.exe is the stuff done by nation state caliber actors such as the old NSA exploits used in the recent WannaCry attacks. Such like 0-day attacks are not targeted at individuals because they simply are too expensive to develop. Additionally, most of these type of exploits are for recon and spying purposes and as such are designed to remain as stealth as possible; if you have one installed, you would never know it.
Once an x64 kernel mode driver has been loaded to kernel space, the only thing that can interface with it is the OS kernel itself.
Kernel memory space cannot be accessed by anything running that is running in user space baring a kernel mode vulnerability.
User memory space can be accessed by the OS kernel. User memory space can be accessed by another user process as long as it has sufficient privileges to do so and the targeted user process is not "protected" as described previously.
AMSI aims to bolster AV memory scans: https://msdn.microsoft.com/en-us/library/windows/desktop/dn889587(v=vs.85).aspx
Here are other protections that are relevant to memory and kernel jacking/persistence, some redundant as itman has already mentioned several
Secure Boot (https://technet.microsoft.com/en-us/library/hh824987.aspx)
Device Guard (https://docs.microsoft.com/en-us/wi...on-based-security-and-code-integrity-policies)
Generic memory protection/EMET (https://blogs.technet.microsoft.com/askpfeplat/2017/04/24/windows-10-memory-protection-features/)
A Fileless Malware Primer - https://www.youtube.com/watch?v=YaxDtpA6pWs
I've read that AV's should be able to detect an in-memory backdoor like DoublePulsar, but normally speaking it's not that hard to evade AV's.
You can use PCHunter64 & Gmer to locate malware in memory in a live windows session, those are your two best options. Use trustworthy offline live cd AV scanners, they do not initiate a potentially infected kernel so viruses cannot hide unless they are signatureless, in firmware or raw disk space; hard reboots are wise if you suspect you are infected, as they will prevent memory resident file-less, signature-less, AV evasive zero-day malware from saving to raw disk or file system so it cannot prepare itself to load again after reboot; wiping free space can be helpful for raw disk malware, zeroing every 8'th byte will save you time; for SSD, initiate trim; repairing MBR may be wise after hardbooting as well as sfc /scannow & dism repair; and keep your firmware up-to-date, even on your CD rom & don't use hardware with vulnerable firmware/chipsets; ~OT comment removed.~
Also lockdown powershell & use windows exploit protections with advanced protections for scripts as a preventative measure against file-less malware infections.
[Environment]::SetEnvironmentVariable(‘__PSLockdownPolicy‘, ‘4’, ‘Machine‘)
Check Language Mode:
Check environment variables under my-computer
Hard reboot may be helpful in an offline scan of the hiber & page file for malware as well, if malware is able to prepare itself for startup upon shutdown, as outlined here: https://technical.nttsecurity.com/post/102dwiw/hibernation-and-page-file-analysis
Here is an interesting way to scan your ram for malware: Malhunt: automated malware search in memory dumps; I believe you could apply this to the page and hiber file as well
The easiest and quickest way, certainly not a forensic route, I will post below
Ram retains data upon shutdown. The slow boot setting in your bios, or extended memory test also clears the ram on boot, much like memtest86+ writes random data to your ram, it just does this once though. This may be a the only way to successfully clear out unknown zero day sophisticated and persistent file-less malware (off the cuff, I'll just say perhaps ring -2 SMM malware, and  if this can wipe its protected memory space), along with clearing the page file on shutdown, (which is basically a compressed copy of your ram) After all, clearing page file on shutdown is the only way to rid persistent malware from swap, as described by sophos here (use startpage and search for the url if you get an error, and load it with the anonymous proxy): https://community.sophos.com/kb/en-us/131782
this would be especially important for people who encrypt their swap; encryption helps with privacy, but also for malware as well; avs won't detect anything inside an encrypted swap file. conversely and ostensibly, if malware cant get inside an encrypted swap, then malware cant data mine an encrypted swap either.
Now if you can tell me how to do this for my Nvidia card ram, I'll be happy. I'm thinking benchmarks, but they'd probably have to run in a live distro or on boot
so simple yet so complete
ps. on some machines the slow boot / extended memory test only happens after a 'shutdown' and not on 'reboot', very convenient.
Update on the previous comment, the next comment will include info on why extended memory tests are redundant.
You might want to read up on GPU-based malware persistence, which can survive a reboot (well, a so-called warm reboot where power is not cut to PCIe devices and they do not enter D3 cold), since the GPU is not necessarily powered down and can perform DMA attacks against system memory once the system is back. My overall point is just that your advice to use POST memory tests is useless, since the malware in the BIOS can override that to protect whatever data it wants to keep in RAM.
should a power down always work
is there some cases where unplugging the power cable may be necessary?
Assuming the GPU malware is only memory resident and exists nowhere else.
Nah, just shut the system down (full power off) and that will cut power to the GPU.
How to put a device into cold power state? Its still up in the air, for windows no question yet, but in linux, forest is still waiting for an answer:
JUST FYI, it takes a good 1-5 minutes for data in ram to decay once system is powered down, if the chips are not first frozen.
(see figure 4)
Forest: Malware that literally persists in RAM after reboot is rendered immediately unreadable for multiple reasons. First, the unallocated memory is never read, and second, LFSR-based memory scrambling destroys the malware. It's impossible for malware to use RAM alone for persistence across reboot. So this answer is wrong.
Me: Can you point to some sources please? Thank you! Also, do all motherboards perform LFSR-based memory scrambling, even systems that date back to 2008, or say 2002? Also take note of the updates to my answer. Some portions of my answer may be, however it may have been SMM malware that had infected his device. I will update it accordingly as I learn more.
Forest: There are no sources for that in the same way there are no sources that prove that malware cannot hide in the screws holding the chassis together. However, you can read about memory scrambling here. https://www.researchgate.net/public..._scrambling_causes_and_impact_on_memory_tests Even if memory scrambling is not used though, unallocated memory (at boot) is simply ignored. It's not read and executed which would be necessary for malware to persist. A booting system doesn't just say "hey, let me try executing everything at every possible offset and any possible"... "fragmentation just in case valid code exists here!" The same is true with hard disks. If you format a disk, even without securely overwriting it, any malware on the disks will be rendered harmless. As for SMM malware, that does not persist across reboot either unless the BIOS is modified to execute malicious SMM at each boot, in which case it's not exclusively memory-resident.
Me: It may not grab onto the memory during post, malware might access that memory section by other means, perhaps an infected firmware or SMM. Also malware may write to empty/raw disk space, and be accessed that at a later time, this is why wiping the free space or running Trim on a harddrive/SSD can also effectively nullify any malware hiding in raw disk space.
Forest: That would still require malware be stored somewhere outside of RAM. If it only existed in RAM, then a reboot completely destroys it. If the malware existed in the BIOS and simply stored some extra data too big for the BIOS in RAM (which I guess would be possible, though I've never seen it and doubt it exists), then enabling POST memory wiping would still be useless, since a compromised BIOS means a compromised POST process. Unless you have something like SRTM using a TPM to measure the BIOS, there's no way to keep yourself safe by using BIOS functionality (RAM tests, ECC initialization, etc).
Me: I hope you are right In the world of electronics however, and constantly evolving threats, I try my best to keep an open mind. I would not be surprised if firmware or chip-set based malware has been used to utilize the ram of a pc.
Forest: You might want to read up on GPU-based malware persistence, which can survive a reboot (well, a so-called warm reboot where power is not cut to PCIe devices and they do not enter D3 cold), since the GPU is not necessarily powered down and can perform DMA attacks against system memory once the system is back. My overall point is just that your advice to use POST memory tests is useless, since the malware in the BIOS can override that to protect whatever data it wants to keep in RAM.
Any malware advanced enough to persist in that manner would also be advanced enough that you could not rely on that kind of security through obscurity to protect from them.
Separate names with a comma.