Obtaining packets/flows for your IBM QRadar - The easy way

In this previous post, I focused on replaying logs in your QRadar lab environment. However, I never took the time to show the same for how you may be able to replay packets/flows. Whereas getting sample events into your QRadar (I believe) is relatively easy, I don't believe the same can be said for packets and flows. However, there are still two quick ways I can think about to get network packet/flows into QRadar. Both of those will be addressed. However, each method will be in its own post.

Method 1:
The first is simply to configure your QRadar device interface to act as a flow source.

First I will look at my IP configuration, to see which interface on the local QRadar device is generating the most traffic. For me this is "ens33". This is also because this is the interface connected on my virtual machine and to which I'm doing SSH and which can access the internet.

[securitynik@qradarCE ~]# ifconfig ens33
ens33: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
        inet 192.168.208.137  netmask 255.255.255.0  broadcast 192.168.208.255
        inet6 fe80::20c:29ff:feca:dff1  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:ca:df:f1  txqueuelen 1000  (Ethernet)
        RX packets 6039  bytes 1122388 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6205  bytes 5163411 (4.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Having identified the interface, let's configure QRadar to listen for flows on this interface.

Now that we have the flow source configured, you need to deploy your changes. You can do this from the "Admin" tab or menu item, then select "Deploy Changes". Once the changes have been deployed, connect to your QRadar via SSH and do some admin work. Then connect to QRadar, go to your "Network Activity" tab and you should see some data as shown below. Here is an example of my output.

That's it for method 1.

See this post for method 2.

Hack and Detect - Mapping a Threat Actor's Tools, Techniques and Procedures (TTP)

One of the critical steps in performing your network forensics analysis, is to be able to generate a visual of what transpired. This visual allows you to get a graphical representation of a threat actor's TTPs.

Below is an example of mapping a threat actor's TTPs from my upcoming book. This graphic below represents the activity performed on a Windows 10 host with an ultimate pivot (lateral movement) to a Windows XP host on another subnet. Note, this all started via a spear-phishing attack. All it took was one click and its game over.

Map of the threat actors Tools, Techniques and Procedures (TTPS), providing Nakia with the necessary intelligence into how this Threat Actor operated, including its lateral movement from the compromised Windows 10 machine to a Windows XP device isolated from the internet.

If you like this mapping of the TTPs, prepare to grab a copy of the book from your favourite seller to learn more about how you can build your own.


You can download the pre-publication sample chapters here while you wait for the published version.

It will be here sooner than you think. Hack and Detect - Leveraging the Cyber Kill Chain for Practical Hacking and its Detection via Network Forensics

Learning by Practicing

Hack & Detect

Leveraging the Cyber Kill Chain for Practical Hacking

and its Detection via Network Forensics  

Author Nik Alleyne

www.securitynik.com

2018-09-01

Currently wrapping up my book and am attaching the Nik Alleyne - Hack and Detect sample chapters for you my readers to get a head start into what to expect. Please note these are sample chapters and not the final product. 

If you have some comments and or suggestions to provide, feel free to either drop me a line or leave a comment below. 

To download click here.

Bro Configuration

The first set of configuration you should do once you install bro, is to tell it the network(s) you would like to protect. Realistically, the first three files you should be looking at are:
node.cfg
networks.cfg
broctl.cfg


Let's start off with networks.cfg

root@securitynik:/opt/bro/etc# cat /opt/bro/etc/networks.cfg
192.168.0.0/24       SecurityNik LAN

For the node.cfg, bro runs in either standalone mode or clustered configuration. I will simulate a clustered configuration on one host. For the clustered configuration we need a Manager, Proxy and a Worker. Also I modified the local hosts file to resolve the following names:

root@securitynik:~# cat /etc/hosts
127.0.0.1       localhost
192.168.0.4     securitynik.n3.local  securitynik
192.168.0.4     securitynik
192.168.0.4     n3-bro-mgr
192.168.0.4     n3-bro-proxy
192.168.0.4     n3-bro-worker

Once the hosts file as been modified, the following represents the node.cfg configuration.

root@securitynik:~# cat /etc/bro/node.cfg
[n3-bro-mgr]
type=manager
host=n3-bro-mgr

[n3-bro-proxy]
type=proxy
host=n3-bro-proxy

[n3-bro-worker]
type=worker
host=n3-bro-worker
interface=enp0s25

Next up let's configure the broctl.cfg. You should check this file to see if ther is anything needed to be modified for your site's specific configuration

root@securitynik:~# cat /opt/bro/etc/broctl.cfg | more

###############################################
# Mail Options

MailTo = root@localhost
MailConnectionSummary = 1
MinDiskSpace = 5
MailHostUpDown = 1

###############################################
# Logging Options
LogRotationInterval = 3600
LogExpireInterval = 0
StatsLogEnable = 1
StatsLogExpireInterval = 0

###############################################
# Other Options

StatusCmdShowAll = 0
CrashExpireInterval = 0
SitePolicyScripts = local.bro
LogDir = /opt/bro/logs
SpoolDir = /opt/bro/spool
CfgDir = /opt/bro/etc

Let's now load up broctl

root@securitynik:~# broctl

Then look at the current status

[BroControl] > status
Name         Type    Host             Status    Pid    Started
n3-bro-mgr   manager n3-bro-mgr       stopped
n3-bro-proxy proxy   n3-bro-proxy     stopped
n3-bro-worker worker  n3-bro-worker    stopped

Once a change was made, we should do an install

[BroControl] > install
removing old policies in /opt/bro/spool/installed-scripts-do-not-touch/site ...
removing old policies in /opt/bro/spool/installed-scripts-do-not-touch/auto ...
creating policy directories ...
installing site policies ...
generating cluster-layout.bro ...
generating local-networks.bro ...
generating broctl-config.bro ...
generating broctl-config.sh ...
updating nodes ...

We then start the different services/roles

[BroControl] > start
starting n3-bro-mgr ...
starting n3-bro-proxy ...
starting n3-bro-worker ...

Verify once again that all services are running

[BroControl] > status
Name         Type    Host             Status    Pid    Started
n3-bro-mgr   manager n3-bro-mgr       running   993    27 Sep 21:58:08
n3-bro-proxy proxy   n3-bro-proxy     running   1039   27 Sep 21:58:10
n3-bro-worker worker  n3-bro-worker    running   1076   27 Sep 21:58:12

Looks good from above.

Looking at the logs below we see:

root@securitynik:~# ls /opt/bro/logs/
2018-09-27  current

Looking specifically at the current logs

root@securitynik:~# ls /opt/bro/logs/current
capture_loss.log   dns.log    known_services.log  stats.log   syslog.log
communication.log  files.log  software.log        stderr.log  weird.log
conn.log           http.log   ssl.log             stdout.log  x509.log

References:
https://www.digitalocean.com/community/tutorials/how-to-install-bro-on-ubuntu-16-04
https://www.bro.org/sphinx/quickstart/index.html

Installing Bro 2.6-beta2

In this post we are looking at installing Bro network and security monitoring framework. I happen to teach this tool in the SANS SEC503 - Intrusion Detection In Depth class and find this to be quite a wonderful tool. As a result, I thought I should put together a quick blog post on its installation and then I can probably build on this post in the future.

Let's get this show on the road.

First up I will be installing on Ubuntu 18.04 (bionic)

root@n3-monitoring:~# lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:        18.04
Codename:       bionic

First I created a directory for "bro" under "/opt"

root@securitynik:~# mkdir /opt/bro

Then installed the necessary dependecies

sudo apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev

Then install geoip

apt-get install libgeoip-dev -y

Change to the GeoIP database

root@securitynik:~# cd /usr/share/GeoIP/

Download the GeoIP files

root@securitynik:~# wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

Unzip the GeoLiteCity files

root@securitynik:~# gunzip GeoLiteCity.dat.gz

Renamed the GeoIP files

root@securitynik:/usr/share/GeoIP# mv GeoLiteCity.dat GeoIPCity.dat

Next up, in my case I switch to the /tmp directory by using "cd /tmp"

Next up, in my case I switch to the /tmp directory by using "cd /tmp", downloaded the file and then untar'd it.

cd /tmp
root@securitynik:/tmp# wget https://www.bro.org/downloads/beta/bro-2.6-beta2.tar.gz
root@securitynik:/tmp# tar -zxvf bro-2.6-beta2.tar.gz

Once the files have been extracted, we next change directory to the "bro-2.6-beta2" directory then run the "configure" scripts/

root@securitynik:/tmp# cd bro-2.6-beta2
root@securitynik:/tmp/bro-2.6-beta2# ./configure --prefix=/opt/bro

====================|  Bro Build Summary  |=====================

Build type:        RelWithDebInfo
Build dir:         /tmp/bro-2.6-beta2/build
Install prefix:    /opt/bro
Bro Script Path:   /opt/bro/share/bro
Debug mode:        false

CC:                /usr/bin/cc
CFLAGS:             -Wall -Wno-unused -O2 -g -DNDEBUG
CXX:               /usr/bin/c++
CXXFLAGS:           -Wall -Wno-unused -std=c++11 -O2 -g -DNDEBUG
CPP:               /usr/bin/c++

Broccoli:          false
Broctl:            true
Aux. Tools:        true

libmaxminddb:      false
Kerberos:          false
gperftools found:  false
        tcmalloc:  false
       debugging:  false
jemalloc:          false

================================================================

Once complete next is to run make followed by make install

root@securitynik:/tmp/bro-2.6-beta2# make
root@securitynik:/tmp/bro-2.6-beta2# make install

Let's now create a symbolic link for bro

root@securitynik:/opt/tmp# ln -s /opt/bro/bin/bro /usr/bin/bro

Let's now install bro-cut via bro-aux

root@securitynik:/opt/tmp# apt-get install bro-aux

Then let's install broctl

root@securitynik:/opt/tmp# apt-get install broctl

Once the install is finished, let's run bro to see what we get:

root@securitynik:/opt/tmp# bro --iface enp0s25
listening on enp0s25

After bro was run for a few minutes and we run ls, we see:

root@securitynik:/opt/tmp# ls *.log
conn.log  packet_filter.log  reporter.log  syslog.log  weird.log

Looks good. Let's now move on to configuring bro.

References:
https://www.bro.org/sphinx/install/install.html
https://blog.rapid7.com/2017/06/24/how-to-install-and-configure-bro-on-ubuntu-linux/
https://www.bro.org/sphinx/frameworks/geoip.html
https://bro-tracker.atlassian.net/browse/BIT-1775

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