📘 Manual

Memory is the best evidence, although the hardest to preserve. If you recall Frozen II “Water has memory”. The same is with this. Even if you delete all the evidence, memory is silently remembering all that. But it’s so fragile….

There are sevaral data types that can hold volatile data i.e. data about some state of RAM in time. Not all of them exist on every system:

• RAM image. Can be aquired for all PC, there are certain complications with a Mac. Also, for mobile devices you can collect RAM data for separate processes only. For virtual machines are usually stored in a separate file once the system is suspended.
• Hibernation files. Exist on major OS (Windows, Mac, Linux). For Windows - hyberfil.sys. It’s a RAM capture made by OS itself when the PC is falling asleep 💤.
• Page files.
• Swap files.
• Crash dumps.

In general, things we are going to do are specific to the case type. It case of a malware infection we will be looking for rogue processes, rootkits and other such things, while in child exploitation or insider threat - these are not top priority. In case of child exploitation we would be more interested in some png or jpeg still residing somewhere in memory.

Why collect RAM?

• User Activity –> File usage and knowledge. Proove someone did something or used something. Common artifacts: Prefetch, Shimcache, Web browser, $MFT (master file table).
• Encryption –> Key files and passwords. Common tools: hashcat, passware.
• Host compromise –> Processes, network activity, malware, rootkits, persistence.

Hibernation files store the last state of RAM before “falling asleep” 💤 . These files are of a particular value when live acquisition is impossible.

🛠 Belkasoft RAM Capturer. ~4Mb footprint in RAM, slow. Magnet RAM Capturer - huge footprint, fast. Dumpit - the fastest, the smallest footprint (didn’t work on Win10 on a VM Parallels on macOS). All of the aforementioned tools run in kernel mode! FTK Imager - big footprint, user mode, doesn’t work on VM (in my case). Benchmark the tools yourself from time to time. Redline, Fast Dump (fdpro.exe). Sumuri’s Interception (included with Paladin). Exploits some memory bug on some OS for machines that have either Thunderbolt or a Firewire to overwrite the admin’s password in memory.

Malfind. https://www.linkedin.com/pulse/process-injection-detection-malfind-britton-manahan/

Windows

Get the Profile Info (vol2)

Purple square - Service pack. Green - correct profile with the correct service pack.

vol.py -f hiberfil.sys --profile=Win7SP0x86 imagecopy -O hyber.raw

Then validate the file by listing processes that were run:

vol.py -f hiberfil.raw pslist --profile=Win7SP0x86

Size up to 75% of memory size.

imagecopy plugin is used to convert some file type into .raw. It decreases the time, needed to analyse the file.

Convert to raw mem

hiberfil files are not as common, but just as good. imagecopy plugin converts different formats into raw format to speed up. Also saves up to 75% of memory size, therefore decreases the time for analysis. First, determine the OS profile (for vol2) and run the plugin. Example:

vol.py -f hiberfil.sys --profile=Win7SP0x86 imagecopy -O hyber.raw

How to get the correct profile since imageinfo gives you several options and kdbscan gives even more? Below is the output from imageinfo. Purple square shows service pack version and the green one - the correct profile with the correct service pack. Other two suggested profiles have some service packs versions appened to the end.

vol.py -f crash.dmp --profile=Win7SP2x64 imagecopy -O crash2mem.raw
vol.py -f hyberfil.sys --profile=Win7SP2x64 imagecopy -O hibir2mem.raw

Running vol.py imageinfo -f hiberfil.sys, for example, is slow and inefficient. No profiles were sugested. But when we have a live capture of a system, we can use this dump to determine the profile to perfom actions with the right profile on hyberfil.sys.

Triage of Windows Core Processes

Deviations = investigative leads. Core Processes - essential for Win, run on any Win system under examination.

• check names
• parent (for example, svchost.exe is started by services.exe)
• expected path
• Singleton?
• Account (local system, mane, users)
• start time (boot time, later)

svchost.exe - the most abused process. Check for above deviations in the result.

Check parent processes of core processes:

grep -E -i "(system|wininit|lsass|lsm|services|sms|taskhost|winlogon|iexplore|explorer|svchost|csrss)" pslist.txt > pslist-all-core.txt

grep -E -i "(system|wininit|lsass|lsm|services|sms|taskhost|winlogon|iexplore|explorer|svchost|csrss)" psscan.txt > psscan-all-core.txt

Check names of non-win processes:

grep -E -i -v "(system|wininit|lsass|lsm|services|sms|taskhost|winlogon|iexplore|explorer|svchost|csrss)"  pslist.txt > pslist-all-non-wincore.txt

grep -E -i -v "(system|wininit|lsass|lsm|services|sms|taskhost|winlogon|iexplore|explorer|svchost|csrss)"  psscan.txt > psscan-all-non-wincore.txt

Check known singletons

grep -E -i "(system|wininit|lsass|services|lsm)" pslist.txt > pslist-all-singletons.txt

grep -E -i "(system|wininit|lsass|services|lsm)" psscan.txt > psscan-all-singletons.txt

In the example above there are two lsass.exe processes which is nonsence. Obviously, some investigative lead.

Check bootimes:

grep -E -i "(system|wininit|lsass|services|sms|lsm|csrss)" pslist.txt > pslist-all-boot.txt

grep -E -i "(system|wininit|lsass|services|sms|lsm|csrss)" psscan.txt > psscan-all-boot.txt

System is a pivot point. Other processes that should start at boot, should have approximately the same starting date and time.

pslist is pulling the information of a doubly-linked list (like a Task Manager). psscan - unallocated space (processes terminated or unlinked from this double-linked list).

Analysis Example

We have the result of pslist:

We have several suspicious processes here: scvhost.exe (misspelled svchost.exe), some xminer.exe and a process with an intriguing name 3.exe. But these are the processes that we could have seen, should we use a Task Manager on a live system. What about terminated or unlinked processes?

To answer that we run psscan:

We seen the same 3.exe in the list. But also we see q.exe which was run for about a minute and during that time another processes was spawned - xmcminer.exe. q.exe was terminated that’s why we don’t see it in pslist results. But xmcminer.exe was not terminated but we still don’t see it in pslist. That means that the process was unlinked from double-list of processes in memory (aka hidden).

Take unique process names, sort and count:

cut -d " " -f 2 'psscan.txt' | sort | uniq -c | sort > 'psscan_proc_sorted.txt'

Also, get all processes that did not start at boot time:

grep -E -i -v 2019-01-20 'pslist.txt' > pslist_not_boottime.txt

grep -E -i -v 2019-01-20 'psscan.txt' > psscan_not_boottime.txt

macOS

SIP?

Linux

Swap space

Mobile

For mobile platforms (iOS and Android) there is currently no tool available to get a full copy of RAM. However, it’s still possible to take memory space of each process running.

💡 Research 🔬 Top secret yet

To get the list of running processes:

To get the memory space of a process:

frida-dump # had some bug for iOS, py file might need manual pathing.
clutch
objection

References

References

[1] Тайны файла подкачки pagefile.sys: полезные артефакты для компьютерного криминалиста

[2] About hybernation files

[3] About new hybernation file format