Project Freta: Microsoft’s Cloud-based Memory Analysis Engine

Nasty Rootkits hiding in memory? No more!

Ah, the sweet days of running your memory sample through volatility. It’s not over yet — but Microsoft has done an amazing job at releasing a new service, which can perform a full-blown volatile memory analysis of a Linux system, with special focus on detecting rootkits.

Let’s go in a little more detail now.

What is ‘Freta’?

‘Project Freta’ is a free, cloud-based solution by Microsoft which can be used to automated full-system volatile memory analysis of Linux systems — the memory has to be acquired in order to generate reports using Freta.

Freta is available for usage/automation via:

• Command-line interface
• Programmatic API (Python )
• Web Portal

Freta is free to use, and available at: Link

Benefits of Freta

• Memory analysis
• Detection of rootkits with focus on in-memory evidence
• Detection of malicious software, hidden processes, and other artefacts
• Searchable evidence across multiple categories e.g. debugged processes, in-memory files, etc.
• Works well with memory samples acquired by tools or virtualization software alike

Acquisition of Memory Image

Freta is compatible with the following memory images:

• Hyper-V memory snapshot (.vmrs)
• LiME image (.lime)
• Elf Core Dump of Physical Memory (.core)
• Raw Physical Memory Dump (.raw)

Note: The goal behind acquiring memory images is to make as less noise as possible, in order to preserve the state of the system. In cases of virtualization, the host captures a snapshot without alarming the guest or the processes running inside it. Running applications on a Linux box itself means generating some noise, modifying system state, and overwriting evidence to some degree.

In order to acquire a memory image, the following techniques can be used:

1. Using AVML (volatile memory acquisition tool)

• Utilizes the interface ‘/proc/kcore’ which isn’t universal to all Linux distributions, and a change of tool might be necessary
• Doesn’t require knowledge of target OS distribution or its kernel
• No modifications to the kernel itself
• Collects output from /dev/crash, /proc/kcore, /dev/me
• Outputs in Linux Memory Extractor (LiME) format, with optional compression

2. Using ‘vmss2core’ to capture VMWare guest snapshots

• Locate the machine’s snapshot
• Run the tool with the -M flag to create a .core file with physical memory
• Capture Linux instance using LiME
• Uses the kernel space for acquisition of RAM
• Dumps over TCP or on local system (good for remote acquisition purposes, especially IR assignments)
• Minimizes interactions but loads the kernel modules (kernel modification is made)

4. Using the Hyper-V Manager

• Create a checkpoint, and find the VMRS file in its directory after completion
• Run it via manager
• Run it via PowerShell

An extensive guide covering each of these steps to acquire a memory sample are provided by Microsoft at: Link

Analysis of Memory Samples on Freta

After a memory sample has been sent to Freta for analysis, the following steps are taken in order:

• Parsing of the memory sample
• Identification of the Kernel (uname -a and e.g. 4.4.0–31-generic)
• Mapping of the kernel — this is where analysis is done, objects are extracted, and the report is populated with findings for a review

Analysis Reports from Freta

The report contains information extracted from the sample and inferences to identify the presence of malware on the system. Following information is available in a single report:

Information

• Kernel name (uname -a)
• Analysis version (Addition to Freta’s codebase and new features could advanced its ability to analyze samples much better — if a new version is available, the analysis can be re-done)

Potential Rootkits

• Identification of potential rootkit behavior with the highest level of privileges (Kernel-space execution)
• Identification of bogus system calls or binary executions with subverted outputs
• Forensic Importance:
• Common hooking methods are available along with their function addresses, names, and other data (if available e.g. two MOV instructions followed by a JMP)
• Identify hooking or interception of calls using Jump (JMP) instructions in which a new routine is added before legitimate code to call arbitrary code
• Refer to the references section for reading into Hooking

Debugged Processes

• A ‘debugged’ process is run under the direct control of the ‘debugging’ process. Generally, all information available within the debugged process is available to the debugging process as well including passwords and cryptographic keys
• Forensic Importance:
• Debugging processes are of much importance, due to extreme privileges assigned to them
• For example, ptrace can be used to observe and control the execution of a different program. If a system-owned process is under control by ptrace, shell-code execution could be a possibility. This can also be a FP on development machines or if well-known processes run the ptrace command (need adequate information of well-known processes)
• Freta analyzes processes which are being debugged and their debugging processes — analyze to see if these programs should be authorized to continue or is this a malicious activity

In-memory Files

• Identify all files which were mapped to the memory during memory acquisition
• Forensic Importance
• Most ELF binaries and DLL’s (shared objects or .so in Linux) will be found loaded into the memory
• Look for suspicious paths from which the binary/SO has been loaded
• Non-standard paths can include /home or /tmp
• Standard paths may include (but not limited to) /usr/lib, /lib, /lib64, and /user/local/lib
• On a Linux box, the ‘lsof’ command can be used to explore the same set of data with appropriate flags
• Difference between the two sets of results must be investigated as well

A default memory sample provided by Freta (total 3 of these)

Kernel Interrupt Table

• Contains a list of interrupts generated against its interrupt handler, and the address at which the handler exists
• Forensic Importance:
• Kernel-mode execution should be limited to a specific set of processes
• Look for signs of Interrupt Hooking
• An interrupt handler is partially responsible for the shift into kernel space, interception of the system call (read from syscall table), jump to the memory address of the originating call, and then executing the code
• The modification of the ‘Interrupt Descriptor Table’ (IDT which stores each interrupt handler’s address) can lead to a bogus handler being calls to execute arbitrary code
• The modification of the interrupt handler can lead to an arbitrary code segment, which could be rootkit code
• Look at bogus memory addresses or interrupt handler names, which doesn’t appear to be a normal name used by generic interrupts (or exceptions — there’s a difference in the two)

Kernel Syscall Table

• Contains a list of system calls executed
• Forensic Importance:
• Two types of system calls are available; 32-bit and 64-bit
• System call names, IDs, and their Kernel memory addresses are provided
• Rootkits can modify memory segments where syscalls jump to, for the execution of the syscall
• Syscall handlers (much like Interrupt handlers) are responsible for calling syscalls, and can be intercepted to include arbitrary code
• Look for bogus memory addresses, or syscall names, which point out

Kernel Modules

• Loadable Kernel Modules (LKMs) are what add to the Kernels ability to implement more features, without frequent recompilation or reboot of the system. Device drivers are an example.
• Forensic Importance:
• Module names, addresses, versions, and sizes are available
• Look for bogus kernel modules which aren’t available on a standard linux box
• Required knowledge of well-known LKMs, to point out the malicious ones
• The command ‘lsmod’ can help identify the status of the LKMS interacting with the kernel (taken from /proc/modules

Networks

• Contains information related to ARP tables and sockets
• Forensic Importance:
• ARP tables can show IP addresses, MAC addresses, and the network interface’s device name
• Socket tables can identify each process with open sockets, their source and destination IP addresses, source and destination ports, it’s current state, and the protocol for the Transport layer
• Identify network connections which are established on that machine and dig into the processes with the PIDs
• This information can also be acquired using ‘ss’, ‘netstat’, and ‘arp’

Open Files

• Open filesystem objects on the system, usually acquired through ‘lsof’
• Forensic Importance:
• Path for each object is available with the PID and process name (titled Comm.)
• Identify bogus network connections, sockets, files, devices, pipes, or anything in particular which doesn’t fit

Processes

• Identify all running processes on a system
• Forensic Importance:
• Following information is available for each process:

1. PID
2. PPID
3. Arguments with which the process launched
4. Current working directory
5. Environment Variables
6. Open Files
7. Sockets

• Identify processes which aren’t normal, launch from a non-standard path, or have a suspicious argument list — also check their environment variables for data loaded while execution

UNIX Sockets

• Sockets used to assist in Inter-process Communication (IPC) calls to exchange data between processes

Photo by Arget on Unsplash

Conclusion

In conclusion, Freta seems to be a promising tool for analysis of memory analysis on Linux systems. Microsoft’s increasing interest in developing for Linux is apparent from their new projects. So, will you be including Freta to your memory analysis toolkit? I definitely will!

References

1. Freta’s Documentation: https://docs.microsoft.com/en-us/security/research/project-freta/report/info

2. Kernel-made Rootkits: https://www.incibe-cert.es/en/blog/kernel-rootkits-en

3. Linux Interrupts: https://linux-kernel-labs.github.io/refs/heads/master/lectures/interrupts.html

4. Hooking (types explained): https://en.wikipedia.org/wiki/Hooking#Netfilter_hook

5. Memory Submission Errors: https://docs.microsoft.com/en-us/security/research/project-freta/troubleshooting-errors