0x00 背景
最近做了一些forensic的调查,随便写一下,随时补充。
0x01 Windows
持久化:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks{xxxxxxx-xxxx-xxxx-AD98-xxxxxxxxxx}
在驱除病毒时,往往仅删除了病毒的注册表文件还不够,需要重启电脑。或者使用命令行删除计划任务或者服务:
sc delete ServiceName
schtasks /delete /tn TaskName
运行历史:
-
Prefetch
-
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache (不重启看不见,可从内存中抽取)
具体方法为: 下载shimcachemem,把shimcachemem.py放入volatility的plugins文件夹里,然后运行python vol.py -f RAM.dmp --profile=Win2008R2SP1x64 shimcachemem
28 2017-09-12 08:12:55 False \??\C:\Windows\OrWvoJaO.exe
但是只能看到文件的最后修改时间,看不到运行时间。最上面的文件是最新被执行的。Exec Flag为True表示文件被执行过,False的话并不能确定是否被执行,比如把鼠标聚焦在文件上,文件的属性被读入内存时也会在shimcache里留下记录,但是因为未被执行,所以是False。另外比如通过batch,或者service启动文件,不是直接执行文件时也会表示为False。
-
注册表里用户的ntuser.dat的UserAssist项目
SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\
这里会显示最后执行时间,但要注意的是这里的文件都是用户从explorer打开才会有记录,命令行里执行的没有记录。
另外比如word文件,jpg,mp4之类的文件名也会在ntuser.dat里有记录。
eventlog:
查询event id的网站:eventid.net。比如输入eventid 7,source处输入symantec,可以查看symantec注册的id为7的event是什么意思。
下面是一些常用event id。
- System 7045: 创建服务
- System 7036: 服务启动
- System 4624: Logon Type 2 (Interactive,比如直接从PC登陆), Type 3 (Network,比如远程登陆,登陆共享的文件系统)
0x02 Linux
- 查询文件系统类型
$ fsck -N disk.image fsck 1.42.13 (17-May-2015) [/sbin/fsck.ext4 (1) -- /] fsck.ext4 disk.image /dev/mapper/vg_1-lv_root [/sbin/fsck.ext4 (1) -- /boot] fsck.ext4 disk.image UUID=e0bd0821-4c24-47bf-bd32-069066e26bcc
-
查询分区起点
$ fdisk -l -u disk.image 設定する必要があります シリンダ数. あなたは特別機能メニューからこれを行なうことができます ディスク disk.image: 0 MB, 0 バイト ヘッド 255, セクタ 63, シリンダ 0, 合計 0 セクタ Units = セクタ数 of 1 * 512 = 512 バイト セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x000c16af デバイス ブート 始点 終点 ブロック Id システム disk.image1 2048 125829119 62913536 83 Linux 領域 1 は異なった物理/論理終点になっています: 物理=(1023, 254, 63) 論理=(7832, 127, 39)
起点为2048 * 512 = 1048576。
- mount
sudo mount -o loop,offset=1048576 disk.image mnt/
或者直接dd:
dd if=disk.image of=disk.image.disk1 skip=2048 bs=512
然后mount
sudo mount -o loop,ro,noexec disk.image.disk1 mnt/
-
使用debugfs分析日志文件
debugfs: ls -d var/spool/cron/ 1311581 (12) . 1311558 (12) .. 1317177 (36) root <1327692> (24) tmp.XXXXnoFifc 1327692 (4036) crontask1 <1327687> (4024) .crontask1.swpx
有尖括号的表示已删除的文件,数字为inode,圆括号里的数字应该是文件大小。
debugfs: show_inode_info <1327687> Inode: 1327687 Type: regular Mode: 0744 Flags: 0x80000 Generation: 1717924669 Version: 0x00000000:00000001 User: 1105 Group: 90 Size: 3066 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 8 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5cade1ca:26f93c28 -- Wed Apr 10 21:30:02 2019 atime: 0x5cade1c9:78092df8 -- Wed Apr 10 21:30:01 2019 mtime: 0x5cade1ca:26f93c28 -- Wed Apr 10 21:30:02 2019 crtime: 0x5cade1c9:78092df8 -- Wed Apr 10 21:30:01 2019 Size of extra inode fields: 28 EXTENTS: (0):11613009
另外使用
logdump -i <inode>
在一些情况下可以看到被删除的文件的block number,结合dd可能可以复原文件。