forensic要素初探

0x00 背景

最近做了一些forensic的调查,随便写一下,随时补充。

0x01 Windows

持久化:

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
  2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\
  3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks{xxxxxxx-xxxx-xxxx-AD98-xxxxxxxxxx}

在驱除病毒时,往往仅删除了病毒的注册表文件还不够,需要重启电脑。或者使用命令行删除计划任务或者服务:

sc delete ServiceName
schtasks /delete /tn TaskName

运行历史:

  1. Prefetch

  2. 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。

  3. 注册表里用户的ntuser.dat的UserAssist项目

    SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\

    这里会显示最后执行时间,但要注意的是这里的文件都是用户从explorer打开才会有记录,命令行里执行的没有记录。
    另外比如word文件,jpg,mp4之类的文件名也会在ntuser.dat里有记录。

eventlog:

  1. System 7045: 创建服务
  2. System 7036: 服务启动

0x02 Linux

  1. 查询文件系统类型
    $ 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
  2. 查询分区起点

    $ 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。

  3. 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/
  4. 使用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 &lt;1327687&gt;
    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可能可以复原文件。