Sunday, June 3, 2018

Remote Live Response with SANS SIFT and F-Response - Analysing the memory

Before I get going, I must confess, I was unable to execute volatility successfully against the Windows 10 machine. I got the "imageinfo" as shown below:
$ vol.py -f /cases/securitynik-win10-pmem.img imageinfo
Volatility Foundation Volatility Framework 2.6
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win10x64_14393, Win10x64_10586, Win10x64, Win2016x64_14393
                     AS Layer1 : Win10AMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/cases/securitynik-win10-pmem.img)
                      PAE type : No PAE
                           DTB : 0x1aa000L
                          KDBG : 0xf800f5ddc4d0L
          Number of Processors : 1
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0xfffff800f4f89000L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2018-06-03 15:38:42 UTC+0000
     Image local date and time : 2018-06-03 11:38:42 -0400

However, when I tried to view the processes, I got:

$ vol.py -f /cases/securitynik-win10-pmem.img --profile=Win10x64_14393 --kdbg=0xf800f5ddc4d0 pslist
Volatility Foundation Volatility Framework 2.6
Offset(V)          Name                    PID   PPID   Thds     Hnds   Sess  Wow64 Start                          Exit                          
------------------ -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
0xffffb5867ce7e478                           4      0 21...2        0 ------      0 6285-08-11 06:06:22 UTC+0000                                 
0xffffb5867e5085b8 `                       320      0 21...0        0 ------      0 6235-10-10 13:14:27 UTC+0000                                 
0xffffb5867ea5d5b8 ???~????csrss.ex        404      0 21...8        0 ------      0 6236-08-31 00:21:17 UTC+0000                                 
0xffffb5867ef31078                         468      0 21...8        0 ------      0 6692-05-05 17:10:47 UTC+0000                                 
0xffffb5867ef205b8 ?=?~????csrss.ex        476      0 21...8        0 ------      0 6236-08-31 00:21:17 UTC+0000                                 
0xffffb5867ef36078                         484    252 21...4        0 ------      0 6236-08-31 07:59:24 UTC+0000                                 
0xffffb5867ef60078 ???~????winlogon        528    344 21...2        0 ------      0 6236-07-21 14:38:47 UTC+0000                                 
0xffffb5867ef7e178 ???~????services        584      0 21...8        0 ------      0 6236-08-31 00:21:17 UTC+0000                                 
0xffffb5867ef335b8 P ?~????lsass.ex        612      0 21...6        0 ------      0 6236-07-21 07:00:39 UTC+0000          

As seen above, it seems at the time of this writing, volatility is unable to properly parse and thus produce the process information for Windows 10 (Build 16299).

As a result, I switched to a Windows 7 machine and grabbed its memory. The Windows 7 host is is at IP 10.0.0.102. Basically using the same methods that were learned in this post.

Here is a quick few commands related to what I did. See this post for the full details.
$ sudo iscsiadm --mode discovery --type sendtargets --portal 10.0.0.102 --debug 7

The above produced:
.....
10.0.0.102:3260,1 iqn.2008-02.com.f-response.securitynik-7:disk-0
10.0.0.102:3260,1 iqn.2008-02.com.f-response.securitynik-7:vol-c
10.0.0.102:3260,1 iqn.2008-02.com.f-response.securitynik-7:pmem

I then attached/connected to physical memory "securitynik-7:pmem" by logging in to it.
$ sudo iscsiadm --mode node --login --targetname iqn.2008-02.com.f-response.securitynik-7:pmem
Logging in to [iface: default, target: iqn.2008-02.com.f-response.securitynik-7:pmem, portal: 10.0.0.102,3260] (multiple)
Login to [iface: default, target: iqn.2008-02.com.f-response.securitynik-7:pmem, portal: 10.0.0.102,3260] successful.

Once again, I take a copy of the memory using:
$ sudo dc3dd if=/dev/sde hof=/cases/securitynik-win7-pmem.img hash=md5 hash=sha256 log=/cases/securitynik-win7-pmem.log verb=on ssz=4096

Now that I have that memory, I can perform the analysis on it.

First up as always, we look at the "imageinfo".
$ vol.py -f /cases/securitynik-win7-pmem.img imageinfo
Volatility Foundation Volatility Framework 2.6
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86
                     AS Layer1 : IA32PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/cases/securitynik-win7-pmem.img)
                      PAE type : No PAE
                           DTB : 0x185000L
                          KDBG : 0x8296ec28L
          Number of Processors : 1
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0x8296fc00L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2018-06-03 18:44:18 UTC+0000
     Image local date and time : 2018-06-03 14:44:18 -0400

Next up let's take a quick look at the snapshot of the processes
$ vol.py -f /cases/securitynik-win7-pmem.img --profile=Win7SP0x86 --kdbg=0x8296ec28 pslist
Volatility Foundation Volatility Framework 2.6
Offset(V)  Name                    PID   PPID   Thds     Hnds   Sess  Wow64 Start                          Exit                          
---------- -------------------- ------ ------ ------ -------- ------ ------ ------------------------------ ------------------------------
0x8483c8f0 System                    4      0     87      506 ------      0 2018-06-03 18:29:27 UTC+0000                                 
0x857a73f0 smss.exe                268      4      2       29 ------      0 2018-06-03 18:29:27 UTC+0000                                 
0x85e13358 smss.exe                336    268      0 --------      0      0 2018-06-03 18:29:28 UTC+0000   2018-06-03 18:29:28 UTC+0000  
0x85732d40 csrss.exe               344    336      8      417      0      0 2018-06-03 18:29:28 UTC+0000                                 
0x857a0d40 smss.exe                384    268      0 --------      1      0 2018-06-03 18:29:28 UTC+0000   2018-06-03 18:29:28 UTC+0000  
0x857a4d40 wininit.exe             392    336      3       75      0      0 2018-06-03 18:29:28 UTC+0000                                 
0x857a0378 csrss.exe               404    384      8      196      1      0 2018-06-03 18:29:28 UTC+0000                                 
0x856fa920 winlogon.exe            444    384      3      112      1      0 2018-06-03 18:29:28 UTC+0000                                 
0x857e3d40 services.exe            488    392      6      228      0      0 2018-06-03 18:29:29 UTC+0000                                 
0x8573f910 lsass.exe               496    392      6      602      0      0 2018-06-03 18:29:29 UTC+0000                                 
0x85743b90 lsm.exe                 504    392     10      148      0      0 2018-06-03 18:29:29 UTC+0000                                 
0x860f7030 svchost.exe             612    488     10      344      0      0 2018-06-03 18:29:30 UTC+0000                                 
0x86169670 VBoxService.ex          676    488     12      117      0      0 2018-06-03 18:29:30 UTC+0000                                 
0x85668d40 svchost.exe             728    488      6      250      0      0 2018-06-03 18:29:30 UTC+0000                                 
0x8567a250 svchost.exe             780    488     19      473      0      0 2018-06-03 18:29:30 UTC+0000                                 
0x861a6518 svchost.exe             888    488     17      424      0      0 2018-06-03 18:29:30 UTC+0000                                 
..................

Let's now wrap this up with looking
$ vol.py -f /cases/securitynik-win7-pmem.img --profile=Win7SP0x86 --kdbg=0x8296ec28 netscan
Volatility Foundation Volatility Framework 2.6
Offset(P)          Proto    Local Address                  Foreign Address      State            Pid      Owner          Created
.......
0x7e632008         TCPv6    :::49154                       :::0                 LISTENING        940      svchost.exe    
0x7e632610         TCPv4    0.0.0.0:49154                  0.0.0.0:0            LISTENING        940      svchost.exe    
0x7e69ed50         TCPv4    0.0.0.0:49157                  0.0.0.0:0            LISTENING        1092     svchost.exe    
0x7e69ed50         TCPv6    :::49157                       :::0                 LISTENING        1092     svchost.exe    
.......
0x7fe39a40         TCPv6    :::10243                       :::0                 LISTENING        4        System         
0x7fd16c58         TCPv4    -:445                          10.0.0.102:49189     CLOSED           4        System         
0x7fd62578         TCPv4    10.0.0.102:3260                10.0.0.101:54156     ESTABLISHED      2132     f-response-ent 
0x7fd747c8         TCPv4    -:49188                        10.0.0.102:445       CLOSED           4        System         
0x7fde9008         TCPv4    -:445                          10.0.0.102:49188     CLOSED           4        System         
0x7fde9df8         TCPv4    -:49213                        10.0.0.102:5681      CLOSED           2132     f-response-ent 

References:
https://github.com/volatilityfoundation/volatility/wiki/Command-Reference


No comments:

Post a Comment