Das Betriebssystem und die Anwendungen eines Computers verwenden den Primärspeicher (oder RAM), um verschiedene Aufgaben auszuführen. Dieser flüchtige Speicher, der eine Fülle von Informationen über laufende Anwendungen, Netzwerkverbindungen, Kernelmodule, geöffnete Dateien und so ziemlich alles andere enthält, wird bei jedem Neustart des Computers gelöscht.
Memory Forensics ist eine Möglichkeit, diese wertvollen Informationen aus dem Gedächtnis zu finden und zu extrahieren. Volatilität ist ein Open-Source-Tool, das Plugins verwendet, um diese Art von Informationen zu verarbeiten. Es gibt jedoch ein Problem: Bevor Sie diese Informationen verarbeiten können, müssen Sie den physischen Speicher in eine Datei speichern, und Volatilität hat diese Fähigkeit nicht.
Daher besteht dieser Artikel aus zwei Teilen:
- Der erste Teil befasst sich mit der Beschaffung des physischen Speichers und dem Ablegen in eine Datei.
- Der zweite Teil verwendet Volatilität, um Informationen aus diesem Speicherauszug zu lesen und zu verarbeiten.
Ich habe das folgende Testsystem für dieses Tutorial verwendet, aber es funktioniert auf jeder Linux-Distribution:
$ cat /etc/redhat-release
Red Hat Enterprise Linux release 8.3 (Ootpa)
$
$ uname -r
4.18.0-240.el8.x86_64
$
Ein Hinweis zur Vorsicht: Teil 1 beinhaltet das Kompilieren und Laden eines Kernelmoduls. Mach dir keine Sorge; es ist nicht so schwierig, wie es sich anhört. Einige Richtlinien:
- Folge den Schritten.
- Versuchen Sie keinen dieser Schritte auf einem Produktionssystem oder Ihrem primären Computer.
- Verwenden Sie immer eine virtuelle Testmaschine (VM), um Dinge auszuprobieren, bis Sie mit den Tools vertraut sind und verstehen, wie sie funktionieren.
Installieren Sie die erforderlichen Pakete
Installieren Sie die erforderlichen Tools, bevor Sie beginnen. Wenn Sie eine Debian-basierte Distribution verwenden, verwenden Sie das Äquivalent apt-get Befehle. Die meisten dieser Pakete enthalten die erforderlichen Kernel-Informationen und Tools zum Kompilieren des Codes:
$ yum install kernel-headers kernel-devel gcc elfutils-libelf-devel make git libdwarf-tools python2-devel.x86_64-yTeil 1: Verwenden Sie LiME, um Speicher zu erwerben und in eine Datei zu speichern
Bevor Sie mit der Speicheranalyse beginnen können, benötigen Sie einen Speicherabzug. In einem tatsächlichen Forensik-Ereignis könnte dies von einem kompromittierten oder gehackten System ausgehen. Solche Informationen werden häufig gesammelt und gespeichert, um zu analysieren, wie der Einbruch geschah und welche Auswirkungen er hat. Da Ihnen wahrscheinlich kein Speicherabbild zur Verfügung steht, können Sie ein Speicherabbild Ihrer Test-VM erstellen und damit Speicherforensiken durchführen.
Linux Memory Extractor (LiME) ist ein beliebtes Tool zum Erfassen von Speicher auf einem Linux-System. Holen Sie sich LiME mit:
$ git clone https://github.com/504ensicsLabs/LiME.git
$
$ cd LiME/src/
$
$ ls
deflate.c disk.c hash.c lime.h main.c Makefile Makefile.sample tcp.c
$
Erstellen Sie das LiME-Kernelmodul
Führen Sie die make Befehl innerhalb der src Mappe. Dadurch wird ein Kernelmodul mit der Erweiterung .ko erstellt. Idealerweise ist die lime.ko Datei wird mit dem Format umbenannt lime-<your-kernel-version>.ko am Ende von make:
$ make
make -C /lib/modules/4.18.0-240.el8.x86_64/build M="/root/LiME/src" modules
make[1]: Entering directory '/usr/src/kernels/4.18.0-240.el8.x86_64'
<< snip >>
make[1]: Leaving directory '/usr/src/kernels/4.18.0-240.el8.x86_64'
strip --strip-unneeded lime.ko
mv lime.ko lime-4.18.0-240.el8.x86_64.ko
$
$
$ ls -l lime-4.18.0-240.el8.x86_64.ko
-rw-r--r--. 1 root root 25696 Apr 17 14:45 lime-4.18.0-240.el8.x86_64.ko
$
$ file lime-4.18.0-240.el8.x86_64.ko
lime-4.18.0-240.el8.x86_64.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), BuildID[sha1]=1d0b5cf932389000d960a7e6b57c428b8e46c9cf, not stripped
$
Laden Sie das LiME-Kernelmodul
Jetzt ist es an der Zeit, das Kernel-Modul zu laden, um den Systemspeicher zu erhalten. Die insmod Befehl hilft beim Laden des Kernelmoduls; nach dem Laden liest das Modul den primären Speicher (RAM) Ihres Systems und schreibt den Inhalt des Speichers in die Datei, die im path Verzeichnis auf der Kommandozeile. Ein weiterer wichtiger Parameter ist format; behalte das Format lime, Wie nachfolgend dargestellt. Überprüfen Sie nach dem Einfügen des Kernelmoduls, ob es geladen wurde, indem Sie das lsmod Befehl:
$ lsmod | grep lime
$
$ insmod ./lime-4.18.0-240.el8.x86_64.ko "path=../RHEL8.3_64bit.mem format=lime"
$
$ lsmod | grep lime
lime 16384 0
$
Sie sollten sehen, dass die Datei an die path Befehl erstellt wurde, und die Dateigröße ist (nicht überraschend) dieselbe wie die physische Speichergröße (RAM) auf Ihrem System. Sobald Sie den Speicherabzug haben, können Sie das Kernel-Modul mit dem entfernen rmmod Befehl:
$
$ ls -l ~/LiME/RHEL8.3_64bit.mem
-r--r--r--. 1 root root 4294544480 Apr 17 14:47 /root/LiME/RHEL8.3_64bit.mem
$
$ du -sh ~/LiME/RHEL8.3_64bit.mem
4.0G /root/LiME/RHEL8.3_64bit.mem
$
$ free -m
total used free shared buff/cache available
Mem: 3736 220 366 8 3149 3259
Swap: 4059 8 4051
$
$ rmmod lime
$
$ lsmod | grep lime
$
Was steht im Speicherabzug?
Diese Dump-Datei besteht nur aus Rohdaten, wie Sie anhand der file Befehl unten. Sie können manuell nicht viel daraus machen; ja, irgendwo sind ASCII-Strings drin, aber Sie können die Datei nicht in einem Editor öffnen und auslesen. Die hexdump-Ausgabe zeigt, dass die ersten paar Bytes sind EmiL; Dies liegt daran, dass Ihr Anfrageformat im obigen Befehl “lime” war:
$ file ~/LiME/RHEL8.3_64bit.mem
/root/LiME/RHEL8.3_64bit.mem: data
$
$ hexdump -C ~/LiME/RHEL8.3_64bit.mem | head
00000000 45 4d 69 4c 01 00 00 00 00 10 00 00 00 00 00 00 |EMiL............|
00000010 ff fb 09 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 b8 fe 4c cd 21 44 00 32 20 00 00 2a 2a 2a 2a 2a |..L.!D.2 ..*****|
00000030 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a |****************|
00000040 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 20 00 20 |************* . |
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000080 00 00 00 00 00 00 00 00 00 00 00 00 70 78 65 6c |............pxel|
00000090 69 6e 75 78 2e 30 00 00 00 00 00 00 00 00 00 00 |inux.0..........|
000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
$
Teil 2: Holen Sie sich Volatilität und analysieren Sie damit Ihren Speicherabzug
Nachdem Sie nun einen Beispielspeicherabzug zum Analysieren haben, rufen Sie die Volatility-Software mit dem folgenden Befehl ab. Volatility wurde in Python 3 neu geschrieben, aber dieses Tutorial verwendet das ursprüngliche Volatility-Paket, das Python 2 verwendet. Wenn Sie mit Volatility 3 experimentieren möchten, laden Sie es aus dem entsprechenden Git-Repository herunter und verwenden Sie Python 3 anstelle von Python 2 in den folgenden Befehlen :
$ git clone https://github.com/volatilityfoundation/volatility.git
$
$ cd volatility/
$
$ ls
AUTHORS.txt contrib LEGAL.txt Makefile PKG-INFO pyinstaller.spec resources tools vol.py
CHANGELOG.txt CREDITS.txt LICENSE.txt MANIFEST.in pyinstaller README.txt setup.py volatility
$
Volatility verwendet für einige Funktionen zwei Python-Bibliotheken, also installieren Sie sie bitte mit den folgenden Befehlen. Andernfalls werden möglicherweise einige Importfehler angezeigt, wenn Sie das Volatilitätstool ausführen. Sie können sie ignorieren, es sei denn, Sie führen ein Plugin aus, das diese Bibliotheken benötigt; In diesem Fall gibt das Tool einen Fehler aus:
$ pip2 install pycrypto
$ pip2 install distorm3
Linux-Profile von Volatility auflisten
Der erste Volatility-Befehl, den Sie ausführen möchten, listet auf, welche Linux-Profile verfügbar sind. Der Haupteinstiegspunkt zum Ausführen von Volatilitätsbefehlen ist der vol.py Skript. Rufen Sie es mit dem Python 2-Interpreter auf und geben Sie die --info Möglichkeit. Um die Ausgabe einzugrenzen, suchen Sie nach Zeichenfolgen, die mit Linux beginnen. Wie Sie sehen, sind nicht viele Linux-Profile aufgeführt:
$ python2 vol.py --info | grep ^Linux
Volatility Foundation Volatility Framework 2.6.1
LinuxAMD64PagedMemory - Linux-specific AMD 64-bit address space.
$
Erstellen Sie Ihr eigenes Linux-Profil
Linux-Distributionen sind vielfältig und für verschiedene Architekturen gebaut. Aus diesem Grund sind Profile unerlässlich – Volatilität muss das System und die Architektur kennen, von denen der Speicherabzug erfasst wurde, bevor Informationen extrahiert werden. Es gibt Volatilitätsbefehle, um diese Informationen zu finden; diese Methode ist jedoch zeitaufwendig. Um die Dinge zu beschleunigen, erstellen Sie mit den folgenden Befehlen ein benutzerdefiniertes Linux-Profil.
Wechseln Sie in die tools/linux Verzeichnis im Volatility Repo und führen Sie das make Befehl:
$ cd tools/linux/
$
$ pwd
/root/volatility/tools/linux
$
$ ls
kcore Makefile Makefile.enterprise module.c
$
$ make
make -C //lib/modules/4.18.0-240.el8.x86_64/build CONFIG_DEBUG_INFO=y M="/root/volatility/tools/linux" modules
make[1]: Entering directory '/usr/src/kernels/4.18.0-240.el8.x86_64'
<< snip >>
make[1]: Leaving directory '/usr/src/kernels/4.18.0-240.el8.x86_64'
$
Du solltest ein neues sehen module.dwarf Datei. Du brauchst auch die System.map Datei aus dem /boot Verzeichnis, da es alle Symbole enthält, die sich auf den aktuell laufenden Kernel beziehen:
$ ls
kcore Makefile Makefile.enterprise module.c module.dwarf
$
$ ls -l module.dwarf
-rw-r--r--. 1 root root 3987904 Apr 17 15:17 module.dwarf
$
$ ls -l /boot/System.map-4.18.0-240.el8.x86_64
-rw-------. 1 root root 4032815 Sep 23 2020 /boot/System.map-4.18.0-240.el8.x86_64
$
$
Um ein benutzerdefiniertes Profil zu erstellen, gehen Sie zurück zum Volatility-Verzeichnis und führen Sie den folgenden Befehl aus. Das erste Argument stellt eine benutzerdefinierte ZIP-Datei mit einem Dateinamen Ihrer Wahl bereit. Ich habe die Betriebssystem- und Kernelversionen im Namen verwendet. Das nächste Argument ist das module.dwarf oben erstellte Datei, und das letzte Argument ist die System.map Datei aus dem /boot Verzeichnis:
$
$ cd volatility/
$
$ zip volatility/plugins/overlays/linux/Redhat8.3_4.18.0-240.zip tools/linux/module.dwarf /boot/System.map-4.18.0-240.el8.x86_64
adding: tools/linux/module.dwarf (deflated 91%)
adding: boot/System.map-4.18.0-240.el8.x86_64 (deflated 79%)
$
Ihr benutzerdefiniertes Profil ist jetzt fertig, überprüfen Sie also, ob die ZIP-Datei am oben angegebenen Speicherort erstellt wurde. Wenn Sie wissen möchten, ob Volatility dieses benutzerdefinierte Profil erkennt, führen Sie die --info Befehl wieder. Diesmal sollten Sie das unten aufgeführte neue Profil sehen:
$
$ ls -l volatility/plugins/overlays/linux/Redhat8.3_4.18.0-240.zip
-rw-r--r--. 1 root root 1190360 Apr 17 15:20 volatility/plugins/overlays/linux/Redhat8.3_4.18.0-240.zip
$
$
$ python2 vol.py --info | grep Redhat
Volatility Foundation Volatility Framework 2.6.1
LinuxRedhat8_3_4_18_0-240x64 - A Profile for Linux Redhat8.3_4.18.0-240 x64
$
$
Beginnen Sie mit Volatilität
Jetzt sind Sie bereit, einige eigentliche Speicherforensiken durchzuführen. Denken Sie daran, dass Volatilität aus benutzerdefinierten Plugins besteht, die Sie gegen einen Speicherabzug ausführen können, um Informationen zu erhalten. Das allgemeine Format des Befehls ist:
python2 vol.py -f <memory-dump-file-taken-by-Lime> <plugin-name> --profile=<name-of-our-custom-profile>Bewaffnet mit diesen Informationen, führen Sie die linux_banner Plugin, um zu sehen, ob Sie die richtigen Distributionsinformationen aus dem Speicherabzug identifizieren können:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_banner --profile=LinuxRedhat8_3_4_18_0-240x64
Volatility Foundation Volatility Framework 2.6.1
Linux version 4.18.0-240.el8.x86_64 (mockbuild@vm09.test.com) (gcc version 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)) #1 SMP Wed Sep 23 05:13:10 EDT 2020
$
Linux-Plugins finden
Das hat gut funktioniert, also sind Sie jetzt wahrscheinlich neugierig, wie Sie alle Namen aller Linux-Plugins finden. Es gibt einen einfachen Trick: Führen Sie die --info Befehl und grep für die linux_ Schnur. Es gibt eine Vielzahl von Plugins für unterschiedliche Anwendungen. Hier ist eine unvollständige Liste:
$ python2 vol.py --info | grep linux_
Volatility Foundation Volatility Framework 2.6.1
linux_apihooks - Checks for userland apihooks
linux_arp - Print the ARP table
linux_aslr_shift - Automatically detect the Linux ASLR shift
<< snip >>
linux_banner - Prints the Linux banner information
linux_vma_cache - Gather VMAs from the vm_area_struct cache
linux_volshell - Shell in the memory image
linux_yarascan - A shell in the Linux memory image
$
Überprüfen Sie, welche Prozesse auf dem System ausgeführt wurden, als Sie den Speicherabzug erstellt haben, indem Sie linux_psaux Plugin. Beachten Sie den letzten Befehl in der Liste: Es ist der insmod Befehl, den Sie vor dem Dump ausgeführt haben:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_psaux --profile=LinuxRedhat8_3_4_18_0-240x64
Volatility Foundation Volatility Framework 2.6.1
Pid Uid Gid Arguments
1 0 0 /usr/lib/systemd/systemd --switched-root --system --deserialize 18
2 0 0 [kthreadd]
3 0 0 [rcu_gp]
4 0 0 [rcu_par_gp]
861 0 0 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
869 0 0 /usr/bin/rhsmcertd
875 0 0 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
878 0 0 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
<<< snip >>>
11064 89 89 qmgr -l -t unix -u
227148 0 0 [kworker/0:0]
227298 0 0 -bash
227374 0 0 [kworker/u2:1]
227375 0 0 [kworker/0:2]
227884 0 0 [kworker/0:3]
228573 0 0 insmod ./lime-4.18.0-240.el8.x86_64.ko path=../RHEL8.3_64bit.mem format=lime
228576 0 0
$
Möchten Sie mehr über die Netzwerkstatistiken des Systems erfahren? Führen Sie die linux_netstat Plugin, um den Zustand der Netzwerkverbindungen während des Speicherabbilds zu ermitteln:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_netstat --profile=LinuxRedhat8_3_4_18_0-240x64
Volatility Foundation Volatility Framework 2.6.1
UNIX 18113 systemd/1 /run/systemd/private
UNIX 11411 systemd/1 /run/systemd/notify
UNIX 11413 systemd/1 /run/systemd/cgroups-agent
UNIX 11415 systemd/1
UNIX 11416 systemd/1
<< snip>>
$
Verwenden Sie als Nächstes die linux_mount Plugin, um zu sehen, welche Dateisysteme während des Speicherabbilds gemountet wurden:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_mount --profile=LinuxRedhat8_3_4_18_0-240x64
Volatility Foundation Volatility Framework 2.6.1
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec
cgroup /sys/fs/cgroup/pids cgroup rw,relatime,nosuid,nodev,noexec
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime
/dev/mapper/rhel_kvm--03--guest11-root / xfs rw,relatime
tmpfs /dev/shm tmpfs rw,nosuid,nodev
selinuxfs /sys/fs/selinux selinuxfs rw,relatime
<< snip>>
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,relatime,nosuid,nodev,noexec
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,relatime,nosuid,nodev,noexec
bpf /sys/fs/bpf bpf rw,relatime,nosuid,nodev,noexec
cgroup /sys/fs/cgroup/memory cgroup ro,relatime,nosuid,nodev,noexec
cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,nosuid,nodev,noexec
mqueue /dev/mqueue mqueue rw,relatime
$
Neugierig, welche Kernelmodule geladen wurden? Volatilität hat auch dafür ein Plugin mit dem treffenden Namen linux_lsmod:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_lsmod --profile=LinuxRedhat8_3_4_18_0-240x64
Volatility Foundation Volatility Framework 2.6.1
ffffffffc0535040 lime 20480
ffffffffc0530540 binfmt_misc 20480
ffffffffc05e8040 sunrpc 479232
<< snip >>
ffffffffc04f9540 nfit 65536
ffffffffc0266280 dm_mirror 28672
ffffffffc025e040 dm_region_hash 20480
ffffffffc0258180 dm_log 20480
ffffffffc024bbc0 dm_mod 151552
$
Möchten Sie alle Befehle finden, die der Benutzer ausgeführt hat und die im Bash-Verlauf gespeichert wurden? Führen Sie die linux_bash Plugin:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_bash --profile=LinuxRedhat8_3_4_18_0-240x64 -v
Volatility Foundation Volatility Framework 2.6.1
Pid Name Command Time Command
-------- -------------------- ------------------------------ -------
227221 bash 2021-04-17 18:38:24 UTC+0000 lsmod
227221 bash 2021-04-17 18:38:24 UTC+0000 rm -f .log
227221 bash 2021-04-17 18:38:24 UTC+0000 ls -l /etc/zzz
227221 bash 2021-04-17 18:38:24 UTC+0000 cat ~/.vimrc
227221 bash 2021-04-17 18:38:24 UTC+0000 ls
227221 bash 2021-04-17 18:38:24 UTC+0000 cat /proc/817/cwd
227221 bash 2021-04-17 18:38:24 UTC+0000 ls -l /proc/817/cwd
227221 bash 2021-04-17 18:38:24 UTC+0000 ls /proc/817/
<< snip >>
227298 bash 2021-04-17 18:40:30 UTC+0000 gcc prt.c
227298 bash 2021-04-17 18:40:30 UTC+0000 ls
227298 bash 2021-04-17 18:40:30 UTC+0000 ./a.out
227298 bash 2021-04-17 18:40:30 UTC+0000 vim prt.c
227298 bash 2021-04-17 18:40:30 UTC+0000 gcc prt.c
227298 bash 2021-04-17 18:40:30 UTC+0000 ./a.out
227298 bash 2021-04-17 18:40:30 UTC+0000 ls
$
Möchten Sie wissen, welche Dateien von welchen Prozessen geöffnet wurden? Verwenden Sie die linux_lsof Plugin, um diese Informationen aufzulisten:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_lsof --profile=LinuxRedhat8_3_4_18_0-240x64
Volatility Foundation Volatility Framework 2.6.1
Offset Name Pid FD Path
------------------ ------------------------------ -------- -------- ----
0xffff9c83fb1e9f40 rsyslogd 71194 0 /dev/null
0xffff9c83fb1e9f40 rsyslogd 71194 1 /dev/null
0xffff9c83fb1e9f40 rsyslogd 71194 2 /dev/null
0xffff9c83fb1e9f40 rsyslogd 71194 3 /dev/urandom
0xffff9c83fb1e9f40 rsyslogd 71194 4 socket:[83565]
0xffff9c83fb1e9f40 rsyslogd 71194 5 /var/log/messages
0xffff9c83fb1e9f40 rsyslogd 71194 6 anon_inode:[9063]
0xffff9c83fb1e9f40 rsyslogd 71194 7 /var/log/secure
<< snip >>
0xffff9c8365761f40 insmod 228573 0 /dev/pts/0
0xffff9c8365761f40 insmod 228573 1 /dev/pts/0
0xffff9c8365761f40 insmod 228573 2 /dev/pts/0
0xffff9c8365761f40 insmod 228573 3 /root/LiME/src/lime-4.18.0-240.el8.x86_64.ko
$
Greifen Sie auf den Speicherort der Linux-Plugins-Skripte zu
Sie können viel mehr Informationen erhalten, indem Sie den Speicherabzug lesen und die Informationen verarbeiten. Wenn Sie Python kennen und neugierig sind, wie diese Informationen verarbeitet wurden, gehen Sie in das Verzeichnis, in dem alle Plugins gespeichert sind, wählen Sie eines aus, das Sie interessiert, und sehen Sie, wie Volatility diese Informationen erhält:
$ ls volatility/plugins/linux/
apihooks.py common.py kernel_opened_files.py malfind.py psaux.py
apihooks.pyc common.pyc kernel_opened_files.pyc malfind.pyc psaux.pyc
arp.py cpuinfo.py keyboard_notifiers.py mount_cache.py psenv.py
arp.pyc cpuinfo.pyc keyboard_notifiers.pyc mount_cache.pyc psenv.pyc
aslr_shift.py dentry_cache.py ld_env.py mount.py pslist_cache.py
aslr_shift.pyc dentry_cache.pyc ld_env.pyc mount.pyc pslist_cache.pyc
<< snip >>
check_syscall_arm.py __init__.py lsmod.py proc_maps.py tty_check.py
check_syscall_arm.pyc __init__.pyc lsmod.pyc proc_maps.pyc tty_check.pyc
check_syscall.py iomem.py lsof.py proc_maps_rb.py vma_cache.py
check_syscall.pyc iomem.pyc lsof.pyc proc_maps_rb.pyc vma_cache.pyc
$
$
Ein Grund, warum ich Volatility mag, ist, dass es viele Sicherheits-Plugins bietet. Diese Informationen wären manuell schwer zu beschaffen:
linux_hidden_modules - Carves memory to find hidden kernel modules
linux_malfind - Looks for suspicious process mappings
linux_truecrypt_passphrase - Recovers cached Truecrypt passphrases
Die Volatilität ermöglicht es Ihnen auch, eine Shell innerhalb des Speicherabbilds zu öffnen. Anstatt alle oben genannten Befehle auszuführen, können Sie stattdessen Shell-Befehle ausführen und die gleichen Informationen erhalten:
$ python2 vol.py -f ~/LiME/RHEL8.3_64bit.mem linux_volshell --profile=LinuxRedhat8_3_4_18_0-240x64 -v
Volatility Foundation Volatility Framework 2.6.1
Current context: process systemd, pid=1 DTB=0x1042dc000
Welcome to volshell! Current memory image is:
file:///root/LiME/RHEL8.3_64bit.mem
To get help, type 'hh()'
>>>
>>> sc()
Current context: process systemd, pid=1 DTB=0x1042dc000
>>>
Nächste Schritte
Die Speicherforensik ist eine gute Möglichkeit, mehr über die Interna von Linux zu erfahren. Probieren Sie alle Plugins von Volatility aus und studieren Sie ihre Ausgabe im Detail. Denken Sie dann darüber nach, wie diese Informationen Ihnen helfen können, einen Einbruch oder ein Sicherheitsproblem zu identifizieren. Tauchen Sie ein in die Funktionsweise der Plugins und versuchen Sie vielleicht sogar, sie zu verbessern. Und wenn Sie kein Plugin für das gefunden haben, was Sie tun möchten, schreiben Sie eines und senden Sie es an Volatility, damit andere es auch verwenden können.