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

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

Now that we have access to the remote disk as seen in this post, we can now leverage our Linux based disk tools to analyze the remotely attached file system.

Our first move however, is to mount the disk. To mount let's first create a folder name "WIN10-disk" in our current folder

$ mkdir WIN10-disk

Next up let's mount the disk

$ sudo mount --verbose --types ntfs --read-only /dev/sdb2 WIN10-disk/

Verifying the disk has been successfully mounted

$ df -kh
Filesystem      Size  Used Avail Use% Mounted on
udev            981M     0  981M   0% /dev
tmpfs           201M   12M  189M   6% /run
/dev/sda1        79G   58G   18G  77% /
tmpfs          1001M  128K 1000M   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs          1001M     0 1001M   0% /sys/fs/cgroup
tmpfs           201M   60K  200M   1% /run/user/1000
/dev/sdb2        30G   23G  6.7G  78% /home/sansforensics/WIN10-disk

Looks good. As above we see the "/dev/sdb2        30G   23G  6.7G  78% /home/sansforensics/WIN10-disk"

Performing a "ls"

$ ls /home/sansforensics/WIN10-disk/
Documents and Settings  PerfLogs     Program Files        Recovery      swapfile.sys               tmp    WebGoat  xampp
pagefile.sys            ProgramData  Program Files (x86)  $Recycle.Bin  System Volume Information  Users  Windows

Looks good enough at this point. No need for us to go further.

Let's switch to the next post on memory.

Remote Live Response with SANS SIFT and F-Response - Getting access to the data

Before we get going, it is assumed that you have already configured and installed F-Response on your client machines. That is you have your dongle (FOB), License Manager Monitor, F-Response Enterprise Manager Console with all the necessary configurations.

Let's move on.

Using F-Response and SANS SIFT, we are able to grab a copy and or mount the hard drive and or memory of a remote device. This allows us to interact (as in mount) and or make a copy of the remote device's hard drive and or memory.

For this post, our SANS SIFT which will be our initiator is at IP address 10.0.0.101 as shown below:

$ ifconfig enp0s17
enp0s17   Link encap:Ethernet  HWaddr 08:00:27:33:65:f2  
          inet addr:10.0.0.101  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::d517:64f0:2a5b:8de0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:585830 errors:0 dropped:0 overruns:0 frame:0
          TX packets:262057 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:499362677 (499.3 MB)  TX bytes:15961094 (15.9 MB)

Our remote machine, which is called the target, is a Windows 10 (Build 16299) computer at IP 10.0.0.103 as shown below:

C:\>ipconfig

Windows IP Configuration

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::a049:348c:1e6b:6497%4
   IPv4 Address. . . . . . . . . . . : 10.0.0.103
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

To get started, let's start the iSCSI dameon on our initiator (SANS SIFT)

$ sudo systemctl start iscsid

Verifying the status of the iSCSI dameon

$ sudo systemctl status iscsid
● iscsid.service - iSCSI initiator daemon (iscsid)
   Loaded: loaded (/lib/systemd/system/iscsid.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-06-02 16:56:42 UTC; 2h 11min ago
     Docs: man:iscsid(8)
 Main PID: 1242 (iscsid)
    Tasks: 2
   Memory: 1.8M
      CPU: 1.710s
   CGroup: /system.slice/iscsid.service
           ├─1241 /sbin/iscsid
           └─1242 /sbin/iscsid

Jun 02 16:56:42 forensics systemd[1]: Starting iSCSI initiator daemon (iscsid)...
Jun 02 16:56:42 forensics iscsid[1239]: iSCSI logger with pid=1241 started!
Jun 02 16:56:42 forensics systemd[1]: Started iSCSI initiator daemon (iscsid).
Jun 02 16:56:42 forensics iscsid[1241]: iSCSI daemon with pid=1242 started!
Jun 02 19:06:35 siftworkstation systemd[1]: Started iSCSI initiator daemon (iscsid).

From above we see the session is "active (running)". We see additional information related to the service which can be helpful.

Next up, because our iSCSI target (Windows 10) device requires authentication, we need to configure our "iscsid.conf" file with the credentials information.

$ sudo vi /etc/iscsi/iscsid.conf

In this file, we will modify the section which is within the "CHAP Settings" stanza. Specifically, we will un-comment the line:

#node.session.auth.authmethod = CHAP 

Changing it to:

node.session.auth.authmethod = CHAP

Next we un-comment the following two lines:

node.session.auth.username = username
node.session.auth.password = password

Changing them to:

node.session.auth.username = securitynik
node.session.auth.password = Testing123456

Next up, we need to enable authentication configuration for the discovery mode. As a result, we need to un-comment:

#discovery.sendtargets.auth.authmethod = CHAP

changing it to

discovery.sendtargets.auth.authmethod = CHAP

Similarly, we un-comment the following lines:

#discovery.sendtargets.auth.authmethod = CHAP
#discovery.sendtargets.auth.username = username
#discovery.sendtargets.auth.password = password

and providing the username and password to be used:

discovery.sendtargets.auth.authmethod = CHAP
discovery.sendtargets.auth.username = securitynik
discovery.sendtargets.auth.password = Testing123456

Once those changes have been completed, we write and save our changes.

Now that we have our configuration in place, let's now attempt to discover the our Windows 10 target.

Running a node check before we start our discovery process, we get:

$ iscsiadm -m node
iscsiadm: No records found

Now running our discovery in debug mode 7, so that we can see the messages which are triggered during the connection, we get:

$ sudo iscsiadm --mode discovery --type sendtargets --portal 10.0.0.103 --debug 7
........
iscsiadm: authentication setup complete...
iscsiadm: sendtargets discovery to 10.0.0.103:3260 using isid 0x00023d000000
iscsiadm: resolved 10.0.0.103 to 10.0.0.103
iscsiadm: discovery timeouts: login 15, reopen_cnt 6, auth 45.
iscsiadm: connecting to 10.0.0.103:3260
iscsiadm: connected local port 56976 to 10.0.0.103:3260
iscsiadm: connected to discovery address 10.0.0.103
iscsiadm: discovery session to 10.0.0.103:3260 starting iSCSI login
iscsiadm: sending login PDU with current stage 0, next stage 1, transit 0x80, isid 0x00023d000000 exp_statsn 0
iscsiadm: >    InitiatorName=iqn.1993-08.org.debian:01:3cd8a599b830
iscsiadm: >    InitiatorAlias=forensics
iscsiadm: >    SessionType=Discovery
iscsiadm: >    AuthMethod=CHAP,None
iscsiadm: wrote 48 bytes of PDU header
iscsiadm: wrote 124 bytes of PDU data
iscsiadm: read 48 bytes of PDU header
iscsiadm: read 48 PDU header bytes, opcode 0x23, dlength 39, data 0x56054a3194c0, max 32768
iscsiadm: read 39 bytes of PDU data
iscsiadm: read 1 pad bytes
iscsiadm: finished reading login PDU, 48 hdr, 0 ah, 39 data, 1 pad
iscsiadm: login current stage 0, next stage 0, transit 0x0
iscsiadm: >    AuthMethod=CHAP
iscsiadm: >    TargetPortalGroupTag=1
iscsiadm: login response status 0000
iscsiadm: sending login PDU with current stage 0, next stage 0, transit 0x0, isid 0x00023d000000 exp_statsn 1
iscsiadm: >    CHAP_A=5
iscsiadm: wrote 48 bytes of PDU header
iscsiadm: wrote 12 bytes of PDU data
iscsiadm: read 48 bytes of PDU header
iscsiadm: read 48 PDU header bytes, opcode 0x23, dlength 60, data 0x56054a3194c0, max 32768
iscsiadm: read 60 bytes of PDU data
iscsiadm: finished reading login PDU, 48 hdr, 0 ah, 60 data, 0 pad
iscsiadm: login current stage 0, next stage 0, transit 0x0
iscsiadm: >    CHAP_A=5
iscsiadm: >    CHAP_I=5
iscsiadm: >    CHAP_C=0xb9751cd011bda258bbb0670e284e4d49
iscsiadm: login response status 0000
iscsiadm: sending login PDU with current stage 0, next stage 1, transit 0x80, isid 0x00023d000000 exp_statsn 2
iscsiadm: >    CHAP_N=securitynik
iscsiadm: >    CHAP_R=0xd27b71c4cd9b0c8bde64daa4333a666e
iscsiadm: wrote 48 bytes of PDU header
iscsiadm: wrote 64 bytes of PDU data
iscsiadm: read 48 bytes of PDU header
iscsiadm: read 48 PDU header bytes, opcode 0x23, dlength 0, data 0x56054a3194c0, max 32768
iscsiadm: login response status 0000
iscsiadm: sending login PDU with current stage 1, next stage 3, transit 0x80, isid 0x00023d000000 exp_statsn 3
iscsiadm: >    HeaderDigest=None
iscsiadm: >    DataDigest=None
iscsiadm: >    DefaultTime2Wait=2
iscsiadm: >    DefaultTime2Retain=0
iscsiadm: >    IFMarker=No
iscsiadm: >    OFMarker=No
iscsiadm: >    ErrorRecoveryLevel=0
iscsiadm: >    MaxRecvDataSegmentLength=32768
iscsiadm: wrote 48 bytes of PDU header
iscsiadm: wrote 152 bytes of PDU data
iscsiadm: read 48 bytes of PDU header
iscsiadm: read 48 PDU header bytes, opcode 0x23, dlength 150, data 0x56054a3194c0, max 32768
iscsiadm: read 150 bytes of PDU data
iscsiadm: read 2 pad bytes
iscsiadm: finished reading login PDU, 48 hdr, 0 ah, 150 data, 2 pad
iscsiadm: login current stage 1, next stage 3, transit 0x80
iscsiadm: >    HeaderDigest=None
iscsiadm: >    DataDigest=None
iscsiadm: >    DefaultTime2Wait=2
iscsiadm: >    DefaultTime2Retain=0
iscsiadm: >    IFMarker=No
iscsiadm: >    OFMarker=No
iscsiadm: >    ErrorRecoveryLevel=0
iscsiadm: >    MaxRecvDataSegmentLength=32768
iscsiadm: login response status 0000
iscsiadm: discovery login success to 10.0.0.103
iscsiadm: sending text pdu with CmdSN 1, exp_statsn 1
iscsiadm: >    SendTargets=All
iscsiadm: wrote 48 bytes of PDU header
iscsiadm: wrote 16 bytes of PDU data
iscsiadm: discovery process  10.0.0.103:3260 polling fd 3, timeout in 30.000000 seconds
iscsiadm: read 48 bytes of PDU header
iscsiadm: read 48 PDU header bytes, opcode 0x24, dlength 276, data 0x56054a3194c0, max 32768
iscsiadm: read 276 bytes of PDU data
iscsiadm: finished reading text PDU, 48 hdr, 0 ah, 276 data, 0 pad
iscsiadm: >    TargetName=iqn.2008-02.com.f-response.securitynik-win:disk-0
iscsiadm: >    TargetAddress=10.0.0.103:3260,1
iscsiadm: >    TargetName=iqn.2008-02.com.f-response.securitynik-win:vol-c
iscsiadm: >    TargetAddress=10.0.0.103:3260,1
iscsiadm: >    TargetName=iqn.2008-02.com.f-response.securitynik-win:pmem
iscsiadm: >    TargetAddress=10.0.0.103:3260,1
iscsiadm: discovery session to 10.0.0.103:3260 received text response, 276 data bytes, ttt 0xffffffff, final 0x80
iscsiadm: updating defaults from '/etc/iscsi/iscsid.conf'
iscsiadm: updating defaults from '/etc/iscsi/iscsid.conf'
iscsiadm: updating defaults from '/etc/iscsi/iscsid.conf'
iscsiadm: discovery process to 10.0.0.103:3260 exiting
iscsiadm: disconnecting conn 0x56054a3120e0, fd 3
iscsiadm: searching iqn.2008-02.com.f-response.securitynik-win:disk-0

iscsiadm: found 10.0.0.103,3260,1

iscsiadm: iface iter found default.
iscsiadm: match session [iqn.2008-02.com.f-response.securitynik-win:disk-0,10.0.0.103,3260][default tcp,,]:0
iscsiadm: to [iqn.2008-02.com.f-response.securitynik-win:disk-0,10.0.0.103,3260][default tcp,,]:0
iscsiadm: searching iqn.2008-02.com.f-response.securitynik-win:vol-c

iscsiadm: found 10.0.0.103,3260,1

iscsiadm: iface iter found default.
iscsiadm: match session [iqn.2008-02.com.f-response.securitynik-win:vol-c,10.0.0.103,3260][default tcp,,]:0
iscsiadm: to [iqn.2008-02.com.f-response.securitynik-win:disk-0,10.0.0.103,3260][default tcp,,]:0
iscsiadm: match session [iqn.2008-02.com.f-response.securitynik-win:vol-c,10.0.0.103,3260][default tcp,,]:0
iscsiadm: to [iqn.2008-02.com.f-response.securitynik-win:vol-c,10.0.0.103,3260][default tcp,,]:0
iscsiadm: searching iqn.2008-02.com.f-response.securitynik-win:pmem

iscsiadm: found 10.0.0.103,3260,1

........
iscsiadm: Looking for config file /etc/iscsi/nodes/iqn.2008-02.com.f-response.securitynik-win:pmem/10.0.0.103,3260
10.0.0.103:3260,1 iqn.2008-02.com.f-response.securitynik-win:disk-0
10.0.0.103:3260,1 iqn.2008-02.com.f-response.securitynik-win:vol-c
10.0.0.103:3260,1 iqn.2008-02.com.f-response.securitynik-win:pmem

Note, I've chosen to use "--debug 7" above, because I was having some initial issues with connectivity and authentication. By looking at the debug, I was able to solve this problem.


From below, we see we have access to "securitynik-win:disk-0", "securitynik-win:vol-c" and the physical memory "securitynik-win:pmem
".

10.0.0.103:3260,1 iqn.2008-02.com.f-response.securitynik-win:disk-0
10.0.0.103:3260,1 iqn.2008-02.com.f-response.securitynik-win:vol-c
10.0.0.103:3260,1 iqn.2008-02.com.f-response.securitynik-win:pmem

Next step is for us to connect/attach to our target images. To attach we need to ensure we login.

Let's first connect to "disk-0".

$ sudo iscsiadm --mode node --targetname iqn.2008-02.com.f-response.securitynik-win:disk-0 --login
Logging in to [iface: default, target: iqn.2008-02.com.f-response.securitynik-win:disk-0, portal: 10.0.0.103,3260] (multiple)
Login to [iface: default, target: iqn.2008-02.com.f-response.securitynik-win:disk-0, portal: 10.0.0.103,3260] successful.

This is then followed by "vol-c"

$ sudo iscsiadm --mode node --targetname iqn.2008-02.com.f-response.securitynik-win:vol-c --login
Logging in to [iface: default, target: iqn.2008-02.com.f-response.securitynik-win:vol-c, portal: 10.0.0.103,3260] (multiple)
Login to [iface: default, target: iqn.2008-02.com.f-response.securitynik-win:vol-c, portal: 10.0.0.103,3260] successful.

Finally physical memory "pmen".

$ sudo iscsiadm --mode node --targetname iqn.2008-02.com.f-response.securitynik-win:pmem --login
Logging in to [iface: default, target: iqn.2008-02.com.f-response.securitynik-win:pmem, portal: 10.0.0.103,3260] (multiple)
Login to [iface: default, target: iqn.2008-02.com.f-response.securitynik-win:pmem, portal: 10.0.0.103,3260] successful.

Looking at our "dmesg" output below, we see we have 3 drives which have been attached. These are "sdb", "sdc" and "sdd"

$ dmesg 
[43564.318175] scsi host33: iSCSI Initiator over TCP/IP
[43565.346490] scsi 33:0:0:0: Direct-Access     FRES     securitynik-win  0    PQ: 0 ANSI: 3
[43565.347334] sd 33:0:0:0: Attached scsi generic sg2 type 0
[43565.348464] sd 33:0:0:0: [sdb] 62914560 512-byte logical blocks: (32.2 GB/30.0 GiB)
[43565.348792] sd 33:0:0:0: [sdb] Write Protect is off
[43565.348795] sd 33:0:0:0: [sdb] Mode Sense: 0e 00 00 08
[43565.349815] sd 33:0:0:0: [sdb] Incomplete mode parameter data
[43565.349819] sd 33:0:0:0: [sdb] Assuming drive cache: write through
[43565.356721]  sdb: sdb1 sdb2
[43565.360763] sd 33:0:0:0: [sdb] Attached SCSI disk
[43755.214676] scsi host34: iSCSI Initiator over TCP/IP
[43756.256567] scsi 34:0:0:0: Direct-Access     FRES     securitynik-win  0    PQ: 0 ANSI: 3
[43756.258681] sd 34:0:0:0: Attached scsi generic sg3 type 0
[43756.258726] sd 34:0:0:0: [sdc] 61786112 512-byte logical blocks: (31.6 GB/29.5 GiB)
[43756.259473] sd 34:0:0:0: [sdc] Write Protect is off
[43756.259478] sd 34:0:0:0: [sdc] Mode Sense: 0e 00 00 08
[43756.261317] sd 34:0:0:0: [sdc] Incomplete mode parameter data
[43756.261323] sd 34:0:0:0: [sdc] Assuming drive cache: write through
[43756.351324] sd 34:0:0:0: [sdc] Attached SCSI disk
[43756.351547] sd 34:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[43756.351553] sd 34:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 03 ae c7 f8 00 00 08 00
[43756.351555] blk_update_request: I/O error, dev sdc, sector 61786104
[43756.351691]  connection2:0: detected conn error (1020)
[43760.170090] sd 34:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[43760.170105] sd 34:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 03 ae c7 f8 00 00 08 00
[43760.170112] blk_update_request: I/O error, dev sdc, sector 61786104
[43760.170119] Buffer I/O error on dev sdc, logical block 7723263, async page read
[43760.170229]  connection2:0: detected conn error (1020)
[43786.323143] scsi host35: iSCSI Initiator over TCP/IP
[43787.351029] scsi 35:0:0:0: Direct-Access     FRES     securitynik-win  0    PQ: 0 ANSI: 3
[43787.353378] sd 35:0:0:0: Attached scsi generic sg4 type 0
[43787.354844] sd 35:0:0:0: [sdd] 524272 4096-byte logical blocks: (2.15 GB/2.00 GiB)
[43787.355045] sd 35:0:0:0: [sdd] Write Protect is off
[43787.355048] sd 35:0:0:0: [sdd] Mode Sense: 0e 00 00 08
[43787.355445] sd 35:0:0:0: [sdd] Incomplete mode parameter data
[43787.355449] sd 35:0:0:0: [sdd] Assuming drive cache: write through
[43787.363032] sd 35:0:0:0: [sdd] Attached SCSI disk

Looking at our "fdisk --list" result, we have:

$ sudo fdisk --list /dev/sdb /dev/sdc /dev/sdd
Disk /dev/sdb: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8bfd5be0

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdb1  *       2048  1126399  1124352  549M  7 HPFS/NTFS/exFAT
/dev/sdb2       1126400 62912511 61786112 29.5G  7 HPFS/NTFS/exFAT
Disk /dev/sdc: 29.5 GiB, 31634489344 bytes, 61786112 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x73736572

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdc1       1920221984 3736432267 1816210284   866G 72 unknown
/dev/sdc2       1936028192 3889681299 1953653108 931.6G 6c unknown
/dev/sdc3                0          0          0     0B  0 Empty
/dev/sdc4         27722122   27722568        447 223.5K  0 Empty

Partition table entries are not in disk order.
Disk /dev/sdd: 2 GiB, 2147418112 bytes, 524272 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Now that we are able to see our drives. Let's take a copy of "securitynik-win:disk-0" which is can be seen as drive "Disk /dev/sdb: 30 GiB" using the information we learned in thist post on "DC3dd - Creating a Forensic Image of a USB"

$ sudo dc3dd if=/dev/sdb hof=/cases/securitynik-win10-disk0.img hash=md5 hash=sha256 log=/cases/securitynik-win10-disk0.log verb=on ssz=512

dc3dd 7.2.641 started at 2018-06-03 15:07:23 +0000
compiled options:
command line: dc3dd if=/dev/sdb hof=/cases/securitynik-win10-disk0.img hash=md5 hash=sha256 log=/cases/securitynik-win10-disk0.log verb=on ssz=512
device size: 62914560 sectors (probed),   32,212,254,720 bytes
sector size: 512 bytes (set)
 32212254720 bytes ( 30 G ) copied ( 100% ), 1721 s, 18 M/s                   
 32212254720 bytes ( 30 G ) hashed ( 100% ),  242 s, 127 M/s                  

input results for device `/dev/sdb':
   62914560 sectors in
   0 bad sectors replaced by zeros
   7805b0c1b12f82134d32a87bff928e8f (md5)
   d085187ff29cdcafdc8d0e346ecbf8058b05564ab0d7681e4bfcdf45e0102199 (sha256)

output results for file `/cases/securitynik-win10-disk0.img':
   62914560 sectors out
   [ok] 7805b0c1b12f82134d32a87bff928e8f (md5)
   [ok] d085187ff29cdcafdc8d0e346ecbf8058b05564ab0d7681e4bfcdf45e0102199 (sha256)

dc3dd completed at 2018-06-03 15:36:03 +0000  

Note, above I choose to use the full disk image rather than "securitynik-win:vol-c". I did this as volume C is part of the disk0. By taking disk0, I'm capturing the entire drive.

Now that we have a copy of the disk, let's take a copy of the memory at "securitynik-win:pmem" which is mapped to "Disk /dev/sdd: 2 GiB"

$ sudo dc3dd if=/dev/sdd hof=/cases/securitynik-win10-pmem.img hash=md5 hash=sha256 log=/cases/securitynik-win10-pmem.log verb=on ssz=4096

dc3dd 7.2.641 started at 2018-06-03 15:38:41 +0000
compiled options:
command line: dc3dd if=/dev/sdd hof=/cases/securitynik-win10-pmem.img hash=md5 hash=sha256 log=/cases/securitynik-win10-pmem.log verb=on ssz=4096
device size: 524272 sectors (probed),    2,147,418,112 bytes
sector size: 4096 bytes (set)
  2147418112 bytes ( 2 G ) copied ( 100% ),   91 s, 22 M/s                    
  2147418112 bytes ( 2 G ) hashed ( 100% ),   25 s, 81 M/s                    

input results for device `/dev/sdd':
   524272 sectors in
   0 bad sectors replaced by zeros
   681d714897777cd5b1a81f298ef246bb (md5)
   042e901cab714bf9f694b688af363a91fcc009307d39822ce0769446a9432b5d (sha256)

output results for file `/cases/securitynik-win10-pmem.img':
   524272 sectors out
   [ok] 681d714897777cd5b1a81f298ef246bb (md5)
   [ok] 042e901cab714bf9f694b688af363a91fcc009307d39822ce0769446a9432b5d (sha256)

dc3dd completed at 2018-06-03 15:40:13 +0000

These images can be used later for other offline forensic activities, which we will perform as we go along.

References:
https://f-response.com/blog/accessing-f-response-using-linux
https://www.f-response.com/assets/pdfs/F-ResponseManual.pdf
https://www.f-response.com/software/ee
https://linux.die.net/man/8/iscsiadm
https://wiki.archlinux.org/index.php/ISCSI_Initiator
SecurityNik creating a forensic image of a USB

DC3dd - Creating a Forensic Image of a USB

Since the USB drive being duplicated is being plugged into a Linux based system or more specifically SANS SIFT Workstation, to make sure the drive is easy to detect, let's first clear our dmesg buffer.

For those not aware of dmesg, this "is used to examine or control the kernel ring buffer". By default, it displays all messages from the kernel ring buffer.

To clear the kernel ring buffer, we type:

# dmesg --clear

To ensure the disk is also not automouted, using dconf-editor, I disabled the "automount", "automount-open" and enabled "automount-never" features. This was done by typing using the "dconf-editor"

Once the editor winow opens, then navigate to:

-> org -> gnome -> desktop -> media-handling

From the above, you can then disable the two options.

Now that we have the basics out of the way, let's insert our USB drive and look at the dmesg output.

# dmesg 
[ 2247.780789] usb 2-1: new SuperSpeed USB device number 10 using xhci_hcd
[ 2247.803791] usb 2-1: New USB device found, idVendor=090c, idProduct=1000
[ 2247.803797] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2247.803801] usb 2-1: Product: USB DISK
[ 2247.803804] usb 2-1: Manufacturer: SMI Corporation
[ 2247.803806] usb 2-1: SerialNumber: AAKTVG216KF7TH93
[ 2247.808934] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 2247.809223] scsi host39: usb-storage 2-1:1.0
[ 2248.953289] scsi 39:0:0:0: Direct-Access     SMI      USB DISK         1100 PQ: 0 ANSI: 6
[ 2248.953818] sd 39:0:0:0: Attached scsi generic sg2 type 0
[ 2248.958202] sd 39:0:0:0: [sdb] 62914560 512-byte logical blocks: (32.2 GB/30.0 GiB)
[ 2248.959002] sd 39:0:0:0: [sdb] Write Protect is off
[ 2248.959006] sd 39:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 2248.959812] sd 39:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2248.975287] sd 39:0:0:0: [sdb] Attached SCSI removable disk

From above we see the "Product: USB DISK" and we see also that it has been assigned device "sdb".

If we now perform a "ls /dev/sd*" we see our "sdb" drive.

# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sda5  /dev/sdb

Let's now go ahead with leveraging dc3dd to create our forensics image.

# dc3dd if=/dev/sdb  hof=/cases/nik-usb-sdb.img hash=md5 hash=sha256 log=/cases/nik-usb-sdb.log verb=on ssz=512

To understand the command above:

if=/dev/sdb  -> use the input file /dev/sdb
hof=/cases/nik-usb-sdb.img -> Hash output file /cases/nik-usb-sdb.img
hash=md5 -> Use MD5 hashing algorithym
hash=sha256 -> Use SHA256 hashing algorithym
log=/cases/nik-usb-sdb.log -> Log the output to "/cases/nik-usb-sdb.log"
verb=on -> Enable verbose reporting
ssz=512 -> set the sector size to 512. I got this from the dmesg results

Looking at the results we see:

dc3dd 7.2.641 started at 2018-05-17 02:51:17 +0000
compiled options:
command line: dc3dd if=/dev/sdb hof=/cases/nik-usb-sdb.img hash=md5 hash=sha256 log=/cases/nik-usb-sdb.log verb=on ssz=512
device size: 62914560 sectors (probed),   32,212,254,720 bytes
sector size: 512 bytes (set)
 32212254720 bytes ( 30 G ) copied ( 100% ), 1243 s, 25 M/s                   
 32212254720 bytes ( 30 G ) hashed ( 100% ),  332 s, 93 M/s                   

input results for device `/dev/sdb':
   62914560 sectors in
   0 bad sectors replaced by zeros
   248c65b1d5d0fb63c8b35dd411cc3ed8 (md5)
   3a015e8c91a982c2629d037431953521b9daad811916436b807e2efd0aaef0fd (sha256)

output results for file `/cases/nik-usb-sdb.img':
   62914560 sectors out
   [ok] 248c65b1d5d0fb63c8b35dd411cc3ed8 (md5)
   [ok] 3a015e8c91a982c2629d037431953521b9daad811916436b807e2efd0aaef0fd (sha256)

dc3dd completed at 2018-05-17 03:11:59 +0000

From above we see via the "[ok]" for both the md5 and sha256 hashes that the copy is a perfect image.

At this point, we can now go ahead and perform our forensics on the file "/cases/nik-usb-sdb.img"

References:
http://man7.org/linux/man-pages/man1/dmesg.1.html
https://askubuntu.com/questions/89244/how-to-disable-automount-in-nautiluss-preferences
http://www.manpagez.com/man/1/dc3dd/
https://www.sans.org/reading-room/whitepapers/forensics/forensic-images-viewing-pleasure-35447