Goal for this lab is after we acquire the disk in .E01 format then how can we mount this to linux system for analysis.
দুইটা scenario cover করছি: (A) simple E01 + LVM (single disk), (B) E01 + Software RAID + LVM (multi-disk, যেমন disk1/disk2)
From the linux analysis vm like sansforensic vm, you need to run the following commands.
We need to first create the working directories:
mkdir -p /mnt/case/img /mnt/case/data
E01 + LVM (single disk) - First case.
Step 1 — E01 mount:
ewfmount Webserver.E01 /mnt/case/img
ls -lh /mnt/case/img
total 0
-r--r--r-- 1 root root 32G Feb 16 18:21 ewf1
Ewf1 is a raw disk image. It's size and main disk size are same. This is in read-only mode. See the permission.
Step 2 — See the partition layout:
mmls /mnt/case/img/ewf1
কোন offset-এ কোন partition আছে (boot, lvm ইত্যাদি) note করুন। RAID sign (0xfd) আছে কিনা খেয়াল করুন — থাকলে Scenario B তে যান।
lvscan | grep VulnOSv2-vg
mount -o ro,noexec /dev/VulnOSv2-vg/root /mnt/case/data
You can further confirm this by following commands:
file -s /dev/md127
/dev/md127: Linux rev 1.0 ext4 filesystem data, UUID=fbd719a9-9a94-491d-a5aa-c16aa407a23e (needs journal recovery) (extents) (64bit) (large files) (huge files)
fsstat /dev/md127 | head -20
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext4
Volume Name:
Volume ID: 3ea207a46ac1aaa51d49949aa919d7fb
Last Written at: 2020-02-12 12:36:50 (EST)
Last Checked at: 2020-02-12 07:09:40 (EST)
Last Mounted at: 2020-02-12 07:36:26 (EST)
Unmounted properly
Last mounted on: /boot
Source OS: Linux
Dynamic Structure
Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index
InCompat Features: Filetype, Needs Recovery, Extents, 64bit, Flexible Block Groups,
Read Only Compat Features: Sparse Super, Large File, Huge File, Extra Inode Size
Journal ID: 00
So we know we have ext4 file system and it was last mounted on /boot.
If some reason the raid set did not get automatically activated then we have the following manual option to activate it.
mdadm --examine /dev/loop0
/dev/loop0:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : cccdcc9b:f86a0b98:98df7949:8f2f7bb8
Name : localhost:boot
Creation Time : Wed Feb 12 07:09:35 2020
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 7809024 (3.72 GiB 4.00 GB)
Array Size : 3904512 (3.72 GiB 4.00 GB)
Data Offset : 6144 sectors
Super Offset : 8 sectors
Unused Space : before=6064 sectors, after=201897984 sectors
State : clean
Device UUID : d8ce6d12:2f2b584f:2ee20f39:02e05ee4
Internal Bitmap : 8 sectors from superblock
Update Time : Wed Feb 12 12:39:40 2020
Bad Block Log : 512 entries available at offset 16 sectors
Checksum : 5fe2660d - correct
Events : 46
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
Step 4 — Doing the same for large (LVM):
Step 3 — Non-LVM partition (যেমন /boot) check:
fsstat -o 2048 /mnt/case/img/ewf1 (-o 2048)
or
fsstat -o <boot_start_sector*512> /mnt/case/img/ewf1 (-o 2048*512 = 1048576)
Why we are multiplying it by 512? See the above image. It is written that Units are in 512-byte sectors.
Unmounted Improperly means, it did not shutdown properly.
Step 4 — Now we need to make LVM partition for loopback device:
losetup -rf -o $((<lvm_start_sector>*512)) /mnt/case/img/ewf1
losetup -rf -o $((501760*512)) /mnt/case/img/ewf1
losetup -a (Using this command we can know which loopback device it got. In this case loop0)
file -s /dev/loop0 (It will confirm whether this is LVM2 PV or not.The file command tells us that the loopback device is pointing to a Linux LVM v2 Physical Volume (“LVM2 PV”). So we are on the right track!)
We are using case directory here instead of test directory.
Step 5 — LVM activation:
pvdisplay /dev/loop0 (Finding the VG name. Here lvm is treating /dev/loop0 as physical volume)
vgscan (This will auto scan disk and loopback device for lvm metadata)
vgchange -a y VulnOSv2-vg (Activating lvm)
See we got root and swap_1 logical volume.
এখন /dev/<VG_NAME>/<LV_NAME> device node গুলো usable হয়ে যাবে।
Step 6 — File system type check before mount:
fsstat /dev/<VG_NAME>/<LV_NAME>
fsstat /dev/VulnOSv2-vg/root
Fsstat saying file system is ext4 and unmounted properly. As unmounted properly, so we will be able to mount it in easy way right? But actually not. Let's see.
The following command will give error. For learning purpose I am showing you this. In production IR, you can directly jump to the actual working command.
mkdir /mnt/case/data (We have already created this directory at the beginning, if not create now)
dmesg | tail (This command will tell you recovery required, ro means read-only and purpose of noexec is no malware will be executed inadvertently)
Working command:
mount -o ro,noexec,noload /dev/VulnOSv2-vg/root /mnt/case/data (noload will ignore journal incomplete transaction)
ls /mnt/case/data
mkdir -p /mnt/case/data/boot (boot is already there so I guess no need to create this directory again)
mount -o ro,noexec,loop,offset=$((<boot_start_sector>*512)) /mnt/case/img/ewf1 /mnt/case/data/boot
mount -o ro,noexec,loop,offset=$((2048*512)) /mnt/case/img/ewf1 /mnt/case/data/boot (noload not required here for boot and ext2 because no journal is here)
ls /mnt/case/data/boot
TEARDOWN Once Investigation is done:
umount /mnt/case/data/boot
umount /mnt/case/data
vgchange -a n VulnOSv2-vg
losetup -d /dev/loop0
umount /mnt/case/img
----------------------------------------------------------------------------
Scenario B — একাধিক disk, Software RAID + LVM (যেমন RAID-1) - Second Case:
Step 1 — All E01 mount:
cd /images/lab09
ls
disk1.E01 disk1.E02 disk1.txt disk2.E01 disk2.E02 disk2.txt
(When the disk image is large, then encase chunk that this way .E01, .E02 etc)
mkdir -p /mnt/case/disk1-ewf /mnt/case/disk2-ewf
ewfmount disk1.E01 /mnt/case/disk1-ewf
ewfmount disk2.E01 /mnt/case/disk2-ewf
No need to mount the .E02 for disk1 and disk2 respectively because ewfmount handle that task.
ls -lh /mnt/case/*
/mnt/case/disk1-ewf:
total 0
-r--r--r--. 1 root root 100G Mar 13 14:15 ewf1
/mnt/case/disk2-ewf:
total 0
-r--r--r--. 1 root root 100G Mar 13 14:15 ewf1
Step 2 - Checking the partition style using Sleuthkit's mmls tool/command:
mmls /mnt/case/disk1-ewf/ewf1
mmls /mnt/case/disk2-ewf/ewf1
0xfd means raid partition. দুই disk-এ identical layout হলে সেটা RAID-1 এর ইঙ্গিত।
Step 3 — প্রতিটা RAID volume-এর জন্য loopback (দুই disk থেকেই একই offset-এ)
We have a small RAID volume starting at sector 2048, and a larger RAID volume starting at sector 7817216.
losetup -rf -o $((<boot_start>*512)) /mnt/case/disk1-ewf/ewf1 --> Syntax
losetup -rf -o $((2048*512)) /mnt/case/disk1-ewf/ewf1
losetup -rf -o $((<boot_start>*512)) /mnt/case/disk2-ewf/ewf1 --> Syntax
losetup -rf -o $((2048*512)) /mnt/case/disk2-ewf/ewf1
You will not see any confirmation output in the shell. But if you want to check then you can do so by following:
cat /proc/mdstat (/proc/mdstat will give you a summary of raid devices)
Personalities : [raid1]
md127 : active (read-only) raid1 loop1[1] loop0[0](F)
3904512 blocks super 1.2 [2/1] [_U]
bitmap: 0/1 pages [0KB], 65536KB chunk
unused devices: <none>
To start the RAID set manually, you would run "mdadm -IR /dev/loop0" and "mdadm -IR /dev/loop1". The -I flag is for incremental assembly mode where you are activating one device at a time. -R means start the device running as soon as the required devices are found.
Losetup tool dea amra duita command run korcilam mone ase? Akta loop0 er jonno hoise and arekta loop1 er jonno hoise. -r means read only mode and -f means free loopback device assign hoye jabe.
losetup -rf -o $((<lvm_start>*512)) /mnt/case/disk1-ewf/ewf1 --> Syntax
losetup -rf -o $((7817216*512)) /mnt/case/disk1-ewf/ewf1
losetup -rf -o $((<lvm_start>*512)) /mnt/case/disk2-ewf/ewf1 --> Syntax
losetup -rf -o $((7817216*512)) /mnt/case/disk2-ewf/ewf1
cat /proc/mdstat # নতুন md device (যেমন md126 this time. Previous was md127)
file -s /dev/md126 # LVM2 PV confirm
fsstat /dev/md126 | head -20
Step 5 — LVM activate (On top of RAID device):
pvdisplay /dev/md126 # VG name বের করা. This one for actual data larger raid for lvm.
--- Physical volume ---
PV Name /dev/md126
VG Name grp1
PV Size <96.21 GiB / not usable 2.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 24629
Free PE 0
Allocated PE 24629
PV UUID BXfTcf-PS2q-ng8Y-t2Ed-wCbl-3rCY-vS1H3b
vgscan
Reading all physical volumes. This may take a while...
Found volume group "grp1" using metadata type lvm2
Found volume group "cl" using metadata type lvm2
vgchange -a y grp1 (Activating VG)
2 logical volume(s) in volume group "grp1" now active
lvscan | grep grp1
ACTIVE '/dev/grp1/home' [76.21 GiB] inherit
ACTIVE '/dev/grp1/root' [<20.00 GiB] inherit
After activating the volume group with vgchange, we see two active devices named /dev/grp1/root and /dev/grp1/home. However, it turns out that these names are actually just symbolic links to the real device nodes.
ls -l /dev/grp1
total 0
lrwxrwxrwx. 1 root root 7 Mar 13 22:23 home -> ../dm-3
lrwxrwxrwx. 1 root root 7 Mar 13 22:23 root -> ../dm-4
file -s /dev/dm-4
/dev/dm-4: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
file -s /dev/dm-3
/dev/dm-3: SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs)
fsstat /dev/dm-4
Cannot determine file system type
So /dev/grp1/root is really /dev/dm-4 and /dev/grp1/home is really /dev/dm-3. The file command tells us that these are XFS file systems. Unfortunately, TSK doesn't know how to deal with XFS. But we should at least be able to mount these file systems!
Step 6 — Mounting the file system:
mkdir -p /mnt/case/data
mount -o ro,noexec /dev/grp1/root /mnt/case/data
mount: cannot mount /dev/mapper/grp1-root read-only
dmesg | tail
Well the message may unclear but from our experience we can say that the system was not shutdown properly.
For EXT4 file systems, we used the "noload" option. The equivalent option for XFS is "norecovery"
mount -o ro,noexec,norecovery /dev/grp1/root /mnt/case/data
ls /mnt/case/data
bin dev home lib64 mnt proc run srv tmp var
boot etc lib media opt root sbin sys usr
mount -o ro,noexec,norecovery /dev/grp1/home /mnt/case/data/home (eta xfs file system er jonno)
ls /mnt/lab09/data/home
lab (We found lab directory here)
mount -o ro,noexec,noload /dev/md127 /mnt/case/data/boot (eta ext4 file system er jonno)
ls /mnt/case/data/boot
config-4.18.0-80.el8.x86_64
efi
grub2
initramfs-0-rescue-84860d5e28f14321ba30d13748b38600.img
initramfs-4.18.0-80.el8.x86_64.img
initramfs-4.18.0-80.el8.x86_64kdump.img
loader
lost+found
System.map-4.18.0-80.el8.x86_64
vmlinuz-0-rescue-84860d5e28f14321ba30d13748b38600
vmlinuz-4.18.0-80.el8.x86_64
Hooray! You just manually reassembled a complicated drive layout from a forensic image in E01 format!
Step 7 — Teardown (সব উল্টো order-এ):
umount /mnt/case/data/boot
umount /mnt/case/data/home
umount /mnt/case/data
ls /mnt/case/data
vgchange -a n grp1
0 logical volume(s) in volume group "grp1" now active
lvscan | grep grp1
inactive '/dev/grp1/home' [76.21 GiB] inherit
inactive '/dev/grp1/root' [<20.00 GiB] inherit
Our logical volumes are now "inactive". The RAID sets can be stopped with "mdadm -S" (-S for stop):
mdadm -S /dev/md126
mdadm: stopped /dev/md126
mdadm -S /dev/md127
mdadm: stopped /dev/md127
cat /proc/mdstat
Personalities : [raid1]
unused devices: <none>
The only item left is to shut down the loopback devices using "losetup -d" to detach the device.
losetup -a | grep case | cut -f1 -d:
losetup -d $(losetup -a | grep case | cut -f1 -d:)
umount /mnt/case/disk1-ewf
umount /mnt/case/disk2-ewf
losetup -a (To verify)
Avi
Comments
Post a Comment