Understanding IP Fragmentation Overlapping with Scapy

The following alert was received from a Symantec Endpoint Protection (SEP) device

<179>Jul 10 09:25:14 sep-papw01 SymantecServer: XXX,SHA-256: ,MD-5: ,"Denial of Service 'IP Fragmentation Overlap' attack detected. Description: An IP Fragmentation Overlap attack exploits IP's packet reassembly feature by creating packet fragments with overlapping offset fields, making it impossible for your system to reassemble the packets properly.",Local: 0.0.0.0,Local: XXXX,Remote: ,Remote: XXXX,Remote: 000000000000,Inbound,ICMP,,Begin: 2018-07-10 06:26:10,End: 2018-07-10 06:26:11,Occurrences: 2,Application: ,Location: XXXX,User: XXXX,Domain: XXXX,XXXX Port 0,Remote Port 0,CIDS Signature ID: 0,CIDS Signature string: ,CIDS Signature SubID: 0,Intrusion URL: ,Intrusion Payload URL: 

Our main concern from the message above is "Denial of Service 'IP Fragmentation Overlap' attack detected".

If you are a new Analyst and see this message, you may wonder WTF is this? What does this mean?
Fortunately the above alert also provides a description, which is:
"An IP Fragmentation Overlap attack exploits IP's packet reassembly feature by creating packet fragments with overlapping offset fields, making it impossible for your system to reassemble the packets properly"

 If you are still thinking but Nik, WTF does this mean? Then let's get into solving this mystery.

Your network interface card has a maximum number of bytes it can carry at one time. This is called the MTU or the Maximum Transmission Unit. To see your interface's current MTU, on a Linux device type:

securitynik@securitynik.lab:~# ifconfig | grep --color=always --perl-regexp "mtu.*?$"
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

Above you see, for eth0 interface I have an MTU of 1500 bytes, while on my loopback there is an MTU of 65536 bytes. While we will not be crafting packets as large as 1500 or 65536 bytes, the concept remains the same. If a packet is larger than the MTU then the packet needs to be fragmented or broken up into smaller pieces so that it can traverse your network. When the sending device or network device breaks this packet up, it needs to be reassembled by the receiving host. In order for this reassembly to work properly, data has to be placed at specific offset. If that data overlaps or there are missing fragments, it can impact the successful reassembly of the packets.

Let's craft a "normal" packet with scapy and the string "SecurityNik-IP-Fragmentation" to understand what "normal" should look like before we look at what fragment overlapping looks like.

>>> send(IP(src="1.1.1.1", dst="192.168.208.131")/"SecurityNik-IP-Fragmentation", count=1)

The above produces the following in tcpdump as shown below.

securitynik@securitynik.lab:~# tcpdump -nntvvi any host 1.1.1.1 -X
IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto Options (0), length 48)
    1.1.1.1 > 192.168.208.131:  ip-proto-0 28
 0x0000:  4500 0030 0001 0000 4000 e79f 0101 0101  E..0....@.......
 0x0010:  c0a8 d083 5365 6375 7269 7479 4e69 6b2d  ....SecurityNik-
 0x0020:  4950 2d46 7261 676d 656e 7461 7469 6f6e  IP-Fragmentation

The above represents a packet which is not fragmented. We can tell its not fragmented because among the most important items for fragmentation, is the fact that we see above "offset 0" and "flags none". Another critical component of fragmentation is the IP ID field. Above this is represented by "id 1". As we look above we also see "length 48" which implies this packet is 48 bytes long. Minus the 20 bytes of IP header and we have 28 bytes of data as seen by the "28" above after "ip-proto-0". This means that the string "SecurityNik-IP-Fragmentation" takes up 28 bytes. When counting the offset, we start from 0. Therefore 0-27 will result in 28 bytes.

S  e  c  u  r  i  t  y  N  i  k  -  I  P  -  F  r  a  g  m  e  n  t  a  t  i  o  n
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 

Let's now craft a fragmented packet which has 2 fragment trains to get an idea what fragmentation looks like. In this case, we will break up the string "SecurityNik-IP-Fragmentation". To be specific, the first fragment will contain "SecurityNik-IP-F" while the second fragment contains "ragmentation"

Here is scapy crafting of the packet.

>>> send(IP(src="1.1.1.1", dst="192.168.208.131", id=20, flags=0x1, frag=0)/"SecurityNik-IP-F", count=1)
>>> send(IP(src="1.1.1.1", dst="192.168.208.131", id=20, flags=0x0, frag=2)/"ragmentation", count=1)

Here is tcpdump output

securitynik@securitynik.lab:~# tcpdump -nntvvi any host 1.1.1.1 -X
IP (tos 0x0, ttl 64, id 20, offset 0, flags [+], proto Options (0), length 36)
    1.1.1.1 > 192.168.208.131:  ip-proto-0 16
 0x0000:  4500 0024 0014 2000 4000 c798 0101 0101  E..$....@.......
 0x0010:  c0a8 d083 5365 6375 7269 7479 4e69 6b2d  ....SecurityNik-
 0x0020:  4950 2d46                                IP-F
IP (tos 0x0, ttl 64, id 20, offset 16, flags [none], proto Options (0), length 32)
    1.1.1.1 > 192.168.208.131: ip-proto-0
 0x0000:  4500 0020 0014 0002 4000 e79a 0101 0101  E.......@.......
 0x0010:  c0a8 d083 7261 676d 656e 7461 7469 6f6e  ....ragmentation
 

From above, if we look at the first record, we see "offset 0" and "flags [+]". Notice the IP ID is also the same "id 20". Notice also the "length 36". Once again, minus the 20 byte IP header and there is "16" bytes of data. The second record (fragment) has "offset 16" and "flags [none]". This means the second record should be placed 16 bytes after the first record and there are no more fragments to follow. We know there are no more fragments because the "flags [none]".

From a more visual perspective

S  e  c  u  r  i  t  y  N  i  k  -  I  P  -  F  r  a  g  m  e  n  t  a  t  i  o  n
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 

As you can see from above, there is no overlap. The string "SecurityNik-IP-Fragmentation" looks much the same as the "normal" packet we discussed above. The "S" starts at 0 and the "r" starts at offset 16.

Now that we have the basics out of the way, let's now look at the overlap. To help, let's craft the same packet again, this time modifying the offset to ensure they overlap. Whereas above "frag=2" was used, below "frag=1" will be used. To get a better understanding of these numbers, you have to multiply then by "8". Hence the "frag=2" is offset 16 and "frag=1" will be offset "8"

And the tcpdump output

securitynik@securitynik.lab:~# tcpdump -nntvvi any host 1.1.1.1 -X
IP (tos 0x0, ttl 64, id 20, offset 0, flags [+], proto Options (0), length 36)
    1.1.1.1 > 192.168.208.131:  ip-proto-0 16
 0x0000:  4500 0024 0014 2000 4000 c798 0101 0101  E..$....@.......
 0x0010:  c0a8 d083 5365 6375 7269 7479 4e69 6b2d  ....SecurityNik-
 0x0020:  4950 2d46                                IP-F
IP (tos 0x0, ttl 64, id 20, offset 8, flags [none], proto Options (0), length 32)
    1.1.1.1 > 192.168.208.131: ip-proto-0
 0x0000:  4500 0020 0014 0001 4000 e79b 0101 0101  E.......@.......
 0x0010:  c0a8 d083 7261 676d 656e 7461 7469 6f6e  ....ragmentation

From a more visual perspective

S  e  c  u  r  i  t  y  N  i  k  -  I  P  -  F  
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 
                        r  a  g  m  e  n  t  a  t  i  o  n 
                        8  9  10 11 12 13 14 15 17 18 19 20

As we can see above, the two fragments begin to overlap at offset 8.

Why would a threat actor want to use this you may be asking? The reality is, this can be used to bypass security products such as IDS/IPS if not properly configured.

Ok. That's it for a Understanding IP Fragmentation Overlapping with Scapy

References:
https://wiki.wireshark.org/Ethernet
https://en.wikipedia.org/wiki/Ethernet_frame
https://wiki.wireshark.org/CaptureSetup/Ethernet
https://snort.org/faq/readme-frag3
https://www.plixer.com/blog/general/netflow-security-detecting-ip-fragmentation-exploits-scrutinizer/
http://pld.cs.luc.edu/courses/447/sum08/class3/novak.target_based_frag.pdf
https://www.cs.montana.edu/courses/fall2005/440/slides/slides_20051026_ip_2.pdf
http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm

Host based threat hunting with Australia's Cert DensityScout and Sysinternals's Sigcheck

In this post, I'm looking at using a two different tools to detect the known unknowns. Basically, I will be doing some host based threat hunting. The known in this case refers to files which are known to be malicious. This can be as a result of AntiMalware vendors, VirusTotal, etc.. classifying these files. However, the unknown refers to me not being aware of these being malicious files. Specifically, the tools we will review are Australia Cert DensityScout and Microsoft Sysinternal sigcheck. These tools will help us to identifies anomalies.

As always with any tool you use, you first should look at the help, man page or any other documentation to get an understanding of what the tool does. In our case, there is also good documentation online as shown in the reference section.

To get the help, you can run densityscout without any arguments. It is recommended if you are on a 64 bit windows system to use the x64 version of densityscout.

E:\Tools\densityscout_45\win64>densityscout.exe -pe -p 0.1 -l 0.1 -o c:\tmp\densityscout-results.txt -r c:\

From above, the options are as follows:
-pe -> focus on files that has the PE header. that is the "MZ" signature in its first 2 bytes.
-p 0.1 -> print on the screen files that have a density lower than 0.1
-l 0.1 -> only files that have a density lower than 0.1
-o c:\tmp\densityscout-results.txt -> The output file to which the results should be written
-r c:\ -> start at the root of the C drive and recurse through all sub-directories

After the tool finishes running, we see our file has been created.

E:\Tools\densityscout_45\win64>dir c:\tmp\densityscout-results.txt

 Volume in drive C has no label.
 Volume Serial Number is 080B-A369
 Directory of c:\tmp

2018-06-07  11:21 PM            14,046 densityscout-results.txt
               1 File(s)         14,046 bytes
               0 Dir(s)  44,528,136,192 bytes free

I then moved this file to my analysis machine to sort the value from lowest to highest.

$ sort densityscout-results.txt --reverse > densityscout-results-sorted.txt
$ cat densityscout-results-sorted.txt | more
(0.09947) | c:\Program Files\Microsoft Office\Office16\1033\MSOUC.HXS
(0.09709) | c:\Users\All Users\PCDr\6875\AddOnDownloaded\d1381de6-f6df-4c78-9412-f365e1907833.dll
(0.09709) | c:\ProgramData\PCDr\6875\AddOnDownloaded\d1381de6-f6df-4c78-9412-f365e1907833.dll
(0.09167) | c:\PortablApps\PortableApps\YUMIPortable\App\YUMI\YUMI.exe
(0.09061) | c:\Program Files\Microsoft Office\Office16\1033\GRAPH.HXS
(0.09008) | c:\Windows\SoftwareDistribution\Download\9f24bc49f22b4a2eda1267a5c08b0903\amd64_Microsoft-Windows-EditionP
ack-Enterprise-Package~~AMD64~~10.0.17134.1\amd64_windows-defender-am-sigs_31bf3856ad364e35_10.0.17134.1_none_a2054a63
84cba550\mpasdlta.vdm
(0.08639) | c:\Windows\WinSxS\amd64_microsoft-windows-p..urepassword-library_31bf3856ad364e35_10.0.16299.15_none_33fba
22d1a24c307\Windows.UI.PicturePassword.dll
(0.08639) | c:\Windows\System32\Windows.UI.PicturePassword.dll
(0.08273) | c:\Users\Security Nik\AppData\Roaming\PCDr\Repair\BundleApplicationRepairTool.exe
(0.08273) | c:\home\SecurityNik\AppData\Roaming\PCDr\Repair\BundleApplicationRepairTool.exe
(0.08245) | c:\Users\All Users\Comodo Downloader\cis\download\installs\5080\xml_binaries\ise\ise_installer.exe
(0.08245) | c:\ProgramData\Comodo Downloader\cis\download\installs\5080\xml_binaries\ise\ise_installer.exe
(0.08181) | c:\Users\All Users\Comodo\ISE\ise_installer.exe
(0.08181) | c:\Users\All Users\Comodo\Installer\ise_installer.exe
(0.08181) | c:\Users\All Users\Comodo Downloader\cis\download\installs\5140\xml_binaries\ise\ise_installer.exe
(0.08181) | c:\ProgramData\Comodo\ISE\ise_installer.exe
.................

Now that we have the densityscout data, let's now transition to leveraging Sigcheck.

Running sigcheck:

E:\Tools\SysinternalsSuite>sigcheck -e -c -u -h -vr -s c:\ > c:\tmp\sigCheck.csv
-e -> Scan executable images only
-u -> show only unsigned files
-h -> generate file hshes
-i -> Show the catalog name and signing chain
-vr -> Submit to VirusTotal and open a report via the browser for hahses found to be a malware
-s c:\ -> while searchig the C drive, recurse through the subdirectories
> c:\tmp\sigCheck.csv -> Instead of putting the output on the screen, redirect it to a file named sigCheck.csv

Taking a snapshot of the output from Sigcheck, we get:

E:\Tools\SysinternalsSuite>type c:\tmp\sigCheck.csv | more
Path,Verified,Date,Publisher,Company,Description,Product,Product Version,File Version,Machine Type,MD5,SHA1,PESHA1,PESHA256,SHA256,IMP,VT detection,VT link
"c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\1031\TrackerUI.dll","Signed","11:30 PM 2017-10-19","Microsoft Corporation","Microsoft Corporation","TrackerUI","Microsoft« Build Tools«","15.0.27019.1","15.0.27019.1 built by: D15REL","32-bit","F29E0E408814D42D57DF21716CD639F5","EE068C956AA94D6D142671BE0587451A0B607F04","7C625DB9CC169B46DA3A2A5CEF7AE898B08912F9","317A7B6ED6BC09E428C40B32E93E28F8CC60EE9B4165FA615A4CEA02541066F2","9AB44675F42B0D6037495FAF00258CA560F7EAA7F19AD0087A8D96C6D4290F2A","n/a","1|66","https://www.virustotal.com/file/9ab44675f42b0d6037495faf00258ca560f7eaa7f19ad0087a8d96c6d4290f2a/analysis/"
"c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\amd64\de\MSBuildTaskHost.resources.dll","Signed","6:06 PM 2017-12-04","Microsoft Corporation","Microsoft Corporation","MSBuildTaskHost.exe","Microsoft« Build Tools«","15.5.180+ge4c819961e","15.5.180.51428","32-bit","493F30FA92F8A9328EB0FE7602D14967","6EDAA34EAC59C858A1B73D28064B182BD2CF020B","E14F7B38A666BE9E85E3C49B890C959952091E7C","80AA7F9B2E3537B481CAFC211A6E5D782F2447B3BF3BC4CE6B6501C1791AAEB7","B732893B0A3965E831F6B2B7A06A3216137CEBE1D3309F1653107DC564EA13C8","DAE02F32A21E03CE65412F6E56942DAA","1|65","https://www.virustotal.com/file/b732893b0a3965e831f6b2b7a06a3216137cebe1d3309f1653107dc564ea13c8/analysis/"
............

From the data returned from Sigcheck, the first thing I did in the interest of time, was to sort the data by the VirusTotal column, to understand VirusTotal ratings of the files starting from highest to lowest.


To achieve my objective, I started off by using the Linux sort utility on the 17th field as the key. However, for whatever strange reason I was not getting the results I expected. This is why we should always be aware of different ways of receiving the same results. As a result, I used "awk" to rewrite the fields so that the 17th column could move to the first and the first moved to the second.

The command below starts by first reading the file Sigcheck.csv. Next a grep was made for the string "Unsigned". This allows us to focus only on the returned results which are unsigned. This was then followed by the awk command to print the 17th and 1st field. Finally, the 12th field is moved to field 3. From the results returned, this was then followed by a grep using perl regular expresion looking for the first column that does not start with the number 1. From the results returned, it was then sorted to keep VirusTotal highes match rate at the top.

$ cat Sigcheck.csv | grep "Unsigned" | awk --field-separator=, '{ print $17","$1","$12 }' | grep --perl-regexp "^[^1]*\|\d+" | sort --uniq --reverse
"4|67","c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\HDHackerPortable\App\HDHacker\HDHacker.exe","5C2D22AAC32335E5F29898473EAEF9D21B38EDD7"
"3|66","c:\Windows\assembly\NativeImages_v4.0.30319_32\Microsoft.Vde5ed89a#\457b4a4c20bed2246e03f1f9e5eaa1a5\Microsoft.VisualStudio.Utilities.Internal.ni.dll","D4B3C929D755B7AD9AAE5D6C64081DE5BD5E4060"
"2|68","c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\IObitUnlockerPortable\App\IObitUnlocker\SysLegacy32\IObitUnlocker.sys","2446597BD4FD1F67657425310BEC5DB5614A8616"
"2|68","c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\FreeUPXPortable\App\FreeUPX\upx394.exe","747159A347C12D394E9576167C234D7DB3D9AB0A"
"2|66","c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\ConverberPortable\App\Converber\Converber.exe","38EF4F2313BF0670B845907F089D5B2873A65F32"
"2|65","c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\FreeUPXPortable\App\FreeUPX\upx393.exe","73AC17C4301274342E69A32E25C2CA2FB84D985B"

Now that we have the results from Sigcheck analysis, let's now see if any of these results also show up in the densityscout report. Leveraging our analysis machine again, we have.

$ cat densityscout-results-sorted.txt | grep --perl-regexp --ignore-case "(HDHacker|IObitUnlocker|upx394|upx393|Converber)"
(0.07310) | c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\HDHackerPortable\App\HDHacker\HDHacker.exe
(0.07310) | c:\PortablApps\PortableApps\HDHackerPortable\App\HDHacker\HDHacker.exe
(0.03109) | c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\FreeUPXPortable\App\FreeUPX\upx393.exe
(0.03109) | c:\PortablApps\PortableApps\FreeUPXPortable\App\FreeUPX\upx393.exe
(0.02833) | c:\VTRoot\HarddiskVolume2\Portable Apps\PortableApps\FreeUPXPortable\App\FreeUPX\upx394.exe
(0.02833) | c:\PortablApps\PortableApps\FreeUPXPortable\App\FreeUPX\upx394.exe

Since we have matches across the two files, we can start with now putting the hashes in VirusTotal or another other site that does this type of analysis and start getting a better understanding of what the file does.

Obviously at this point if there are concerns about these files, they should be removed from your system. Alternatively, you may want to update your own Antimalware solutions and perform a scan to see if it detects these files as malicious. Additionally, you may choose to run it in a confined environment to perform your own analysis.

Ok. That's it for this post. Hope you enjoyed it.


References:
https://www.cert.at/downloads/software/densityscout_en.html
https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck
https://stackoverflow.com/questions/4105956/regex-does-not-contain-certain-characters
https://www.gnu.org/software/gawk/manual/gawk.html
https://regexone.com/lesson/excluding_characters

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