Thursday, December 10, 2015

tcpreplay - Taking a look at packet replaying.

While teaching the SANS 503 (Intrusion Detection In-Depth) Community class last week in Ottawa,  a student asked if the packets are actually replayed to the destination hosts. I stated yes but I thought I should also do a blog post on the topic.

In this example, I'm replaying SSH traffic which was captured earlier in the day and is now being replayed.

The objective of this post is just to show that yes the traffic would go to the destination.

Let's first configure the IP address of the eth0 interface and give it a default route. There is really no  need for the default route as the source and destination are on the same subnet. I just put it there as it is something I typically do. .

Let's verify the interface configuration


While we are attempting to connect to the host at 192.168.0.3, we will also run tcpdump in the background. This allows us write the traffic to a file and then we can replay later.

Now let's try to connect via SSH to the host at 192.168.0.3. Note the date and time.

These connections have all failed.

Now let's replay this traffic.



Let's see how many packets were captured via tcpdump.

Looks like we got 76 packets. If we compare this with the number of packets replayed via tcpreplay, we will see that the 76 matches the number of packets attempted and the 76 which were successful.
Here we have the packets which were sent via tcpreplay


Here we have what iptables saw



Let's compare the two images to see if we can detect this as replayed traffic.

Source Port 35935: The same in the original pcap and in the iptables log.
Destination Ports 22: The same in the original pcap and in the iptables log.
Sequence numbers: Remain the same across both
the pcap and the iptables.log
Acknowledge numbers:
Remain the same across both the pcap and the iptables.log
Flags: The flags are the same



Point to note is that while the traffic is replayed to the host, the application layer did not pick this traffic up and attempt create a SSH session.

So from the above, hopefully if anyone else had a similar questions about replaying of the traffic this post may help to clear it up.

Additional Readings:
http://tcpreplay.synfin.net/wiki/usage
http://tcpreplay.synfin.net/wiki/manual
http://tcpreplay.synfin.net/tcpreplay.html





Wednesday, December 9, 2015

Covert Channels - Part 2 - exfiltrating data through TCP Sequence Number field

A while back I did this blog post on transferring data via the IP ID field.
Recently, I had to do some work on this topic again, so I thought I should now publish the second part which I should have completed a lonnnnnng time ago.

In this post we will look at transferring the "/etc/shadow" file using "covert_tcp" via TCP sequence number field.

Our setup?
Everything is on one system but do note that covert_tcp has a client and server component.
Server configuration



Client configuration and execution


Above we see the client has been loaded and data being transmitted one byte at a time.

Below we see the server receiving data one byte at a time.

















A "ls -al" of the files shows their similarity.





While the data was exfiltrated, I also had "tcpdump" running in the background

Below shows the packets captured.

So what does the capture traffic look like?

How to detect and or mitigate against this type of traffic?

Let's  see what stands out.
1. Large number of SYN packets
If this is a legitimate connection attempt, then we need to see corresponding  SYN-ACK and a final ACK. The fact that there is a large number of SYNs with no complete 3-way handshake should make this standout as suspicious.

2. Large number of corresponding RST-ACKs
Attempts to connect to a port which is not listening should result in a RST-ACK. Therefore the question here should be why the persistence to continue connecting to a port which is not listening. The large number of RST-ACKs as seen in the packet capture should be reason to suspect something malicious.

3. All packets have the same IP length.
This is also strange. I look at this and immediately start to think of a crafted packet or something malicious.

4. The port number is reused.
Every new client connection should have a new source port. The fact that these are all the same suggests that there is something suspicious going on here and an investigation should be performed to determine the nature of this traffic.


So we highlighted a few points above. But is there anything else which can be used to detect this type of activity?! Statistical analysis, anomaly detection, behavioural analysis are all methods that can possibly be used to detect this type of activity. However, the 4 items above are clear signs of something malicious.

References:
http://securitynik.blogspot.ca/2014/04/covert-channels-communicating-over-tcp.html
http://www-scf.usc.edu/~csci530l/downloads/covert_tcp.c
http://firstmonday.org/ojs/index.php/fm/article/view/528/449
Packet Capture - myShadow.pcap



Tuesday, December 8, 2015

Some tshark examples a mix of basic and somewhat advance


Viewing all IP packets
tshark -n -r filename.pcap  -Y "ip"

Viewing all TCP packets

tshark -n -r filename.pcap  -Y "tcp"

Viewing protocol hierarchy
tshark -n -r filename.pcap  -z io,phs -q

View all IP endpoints

tshark -n -r filename.pcap  -z endpoints,ip -q

View all TCP endpoints

tshark -n -r filename.pcap  -z endpoints,tcp -q

View IP conversations
tshark -n -r filename.pcap  -z conv,ip -q

View TCP conversations

tshark -n -r filename.pcap  -z conv,tcp -q

Show tabular view with field headers

tshark -n -r filename.pcap  -T fields -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e tcp.flags -E header=y

Verify that the first two bytes of the IP header is 0x4500
tshark -n -r filename.pcap -x "ip[0:2] == 45:00"

Source IP is 192.168.0.2

tshark -n -r filename.pcap -x "ip[12:4] == c0:a8:00:02"

destination IP is 192.168.0.1

tshark -n -r filename.pcap -x "ip[16:4] == c0:a8:00:01"

Show IPv4 Destinations/Statistics and Ports

tshark -n -r filename.pcap  -z dests,tree -q

Follow TCP stream
tshark -n -r filename.pcap  -z follow,tcp,ascii,0 -q

a few not so basic windump examples

Verify IP verion is 4windump -nvv -r filename.pcap -X "ip[0] & 0xF0 = 0x40"

Verify IP header has no options. That is the IP header is 20 bytes
windump -nvv -r filename.pcap -X "ip[0] & 0x0F = 0x5"

Verify that IP protocl is ICMP

windump -nvv -r filename.pcap -X "ip[9] = 0x01"

Verify that IP protocol is UDP
windump -nvv -r filename.pcap -X "ip[9] = 0x11"

Verify that IP protocol is TCP
windump -nvv -r filename.pcap -X "ip[9] = 0x06"

Determine time to live is less than 128
windump -nvv -r filename.pcap -X "ip[8] < 128"

Tracking IP packets with More Fragments flag set
windump -nvv -r filename.pcap -X ip[6] = 0x20

Verifying that source IP is 10.0.0.6
windump -nvv -r filename.pcap -X "ip[12] = 0x0a && ip[13] = 0x00 && ip[14] = 0x00 && ip[15] = 0x06"

Verifying that destination IP is 151.164.1.8
windump -nvv -r filename.pcap -X "ip[16] = 0x97 && ip[17] = 0xa4 && ip[18] = 0x01 && ip[19] = 0x08"

All traffic from tcp source port = 23
windump -nn -r filename.pcap -X "tcp[0:2] = 23"

All traffic from tcp dst port 1254
windump -nn -r filename.pcap -X "tcp[2:2] = 1254"

All packets with SYN flag set
windump -nn -r filename.pcap -X "tcp[13] = 0x02"

All packets with SYN/ACK flags set
windump -nn -r filename.pcap -X "tcp[13] = 0x12

All packets with FIN flag set
windump -nn -r filename.pcap "tcp[13] & 0x01 = 0x01"

Looks for TCP packets with header length greater than 20 bytes
windump -nn -r filename.pcap "tcp[12] & 0xF0 > 0x50"

Look for packets with the PUSH flag set
windump -nn -r filename.pcap "tcp[13] & 0x08 = 0x08"

References
http://www.tcpdump.org/tcpdump_man.html


Windump basics by examples

Just a quick put together of some basic tcpdump commands.

In this post I will be targeting a .pcap file. However, these commands can be used for live capture

See all packets in the capture file
windump -n -r filename.pcap

Show only the first 2 packets
windump -n -r flename.pcap -c 2

Tracking host by source MAC address
windump -n -r filename.pcap -e "ether src 00:a0:cc:3b:bf:fa"

Tracking host by destination MAC address
windump -n -r filename.pcap -e "ether dst 00:a0:cc:3b:bf:fa"

Tracking host by IP, whether that IP is source or destination
windump -n -r filename.pcap "host 192.168.0.1"

Track host by source IP
windump -n -r filename.pcap "src host 192.168.0.1"

Track host by destination IP
windump -n -r filename.pcap "dst host 192.168.0.1"

Track port even if it is the source or destination
windump -n -r filename.pcap "port 1254"

Tracking a source port
windump -n -r filename.pcap "src port 1254"

Track a destination port
windump -n -r filename.pcap "dst port 1254"

Tracking a UDP specific UDP port
windump -n -r filename.pcap "udp port 1254"

Tracking a specific source UDP port
windump -n -r filename.pcap "udp src port 1254"

Tracking a specific destination udp port
windump -n -r filename.pcap "udp dst port 1254"

Capturing all ARP
windump -n -r filename.pcap "arp"

Capturing all IP packets
windump -n -r filename.pcap "ip"

Capturing all UDP packets
windump -n -r filename.pcap "udp"

Capturing all ICMP packets
windump -n -r filename.pcap "icmp"

Capturing all ICMP packets
windump -n -r filename.pcap "tcp"



References

http://www.tcpdump.org/tcpdump_man.html

Sunday, November 1, 2015

Volatility Memory Forensics - Investigation a potential virus situation - Part 5

Part 1 | Part 2 | Part 3 | Part 4


Final Pass – ShimCache, ShellBags & Prefetch
Before closing off, the decision was made to take a look at the ShimCache, ShellBags and Prefetch to see if there was information there which may contribute to Alyssa’s concerns.

To take a look at the ShimCache the following command was executed “vol.py --filename=./ALYSSA-PC-20150905-001215.raw --verbose --kdbg=0xf6fc0001a0f0 --dtb=0x187000 --profile=Win7SP1x64 shimcache > shimcache-results.txt”. Next the command “cat shimcache-results.txt” was executed. While generally things “seemed normal”, two entries which stood out to me were “MSID117.tmp” which ran from “C:\Windows\Installer” and “setup.exe” being executed from “C:\windows\TEMP\CR_50612”. According to (productforums.google.com, n.d.) this may be related to google update services and may have contributed to the slowness she experienced. The fact that there are other entries related to google around the same time, suggests that this may actually be related to Google products.


Figure 16:Above shows data from shimcache



Peering into the ShellBags to see if anything stands out, did not produce anything that made me want to look further.
To look at the ShellBags, the following command was used “vol.py --filename=./ALYSSA-PC-20150905-001215.raw --verbose --kdbg=0xf6fc0001a0f0 --dtb=0x187000 --profile=Win7SP1x64 shellbags >  shellbag-result.txt”. Next the command “cat shellbag-result.txt” was executed.

Finally, like the ShellBags a review of the Prefectch data did not produce anything which cause me to want to look further. To view the information in Prefetch, the following command was executed “vol.py --filename=./ALYSSA-PC-20150905-001215.raw --verbose --kdbg=0xf6fc0001a0f0 --dtb=0x187000 --profile=Win7SP1x64 prefetchparser > prefetchparser-results.txt”. Next the command “cat prefetchparser-results.txt” was executed.

At this point it was decided to end this analysis as after the efforts which has been extended so far, I have been unable to say with any certainty that this computer is infected.

Conclusion

While initially Alyssa mentioned the computer was running slow and that she thinks she may be infected with a virus, from the memory dump I extracted of her machine I was unable to find any evidence to support her theory from the processes and or network connections which began my initial investigation. More importantly, there can be numerous reasons why I was unable to detect any viruses but simply from the data I examined I was unable to find anything.


References

Limelight Networks Inc. (2014). Annual Report 2014. Tempe, AZ 85281: Limelight Networks Inc. Retrieved from investors.limelightnetworks.com: http://investors.limelightnetworks.com/
productforums.google.com. (n.d.). Google Chrome Help Forum. Retrieved from productforums.google.com: https://productforums.google.com/forum/#!topic/chrome/FZDBl2Jzkok
support.kaspersky.com. (2015, September 17). How to get a dump file of AVP.EXE process for Kaspersky Lab products. Retrieved from support.kaspersky.com: http://support.kaspersky.com/general/dumps/8006


Appendix 

Appendix A: Examiner Workstation Specifications

·         Computer Name: securitynik
·         OS Name: Ubuntu
·         OS Version: 14.04.3 LTS
·         System Make/Model: Virtual Machine
·         System Serial Number: 001122345
·         Time Zone: GMT-4
·         System date/time is consistent with the time zone listed above, as verified by http://nist.time.gov/.


Appendix B: Tools

·         dumpit.exe - v1.3.2.20110401
·         fciv.exe – v2.05
·         UNRAR 5.00 beta 8 freeware
·         Volatility Framework 2.4
·         foremost 1.5.7
·         ClamAV - v0.98.7
·         geoiptool
·         grep – v2.16
·         WinRar 5.11 beta
·         Cat
·         more


Appendix D: Evidence Verification

Table 2 outlines the hashes obtained throughout the evidence verification process. md5sum was used to calculate MD5 hashes.

Designation
Filename
MD5 Hash
Description
PRE-ANALYSIS
Evidence Created
ALYSSA-PC-20150905-001215.rar
88f81f7990fb1b2e18080b6ca4744433
Image created
Evidence Examined
ALYSSA-PC-20150905-001215.rar
88f81f7990fb1b2e18080b6ca4744433
Image examined
POST-ANALYSIS
Evidence Created
ALYSSA-PC-20150905-001215.rar
88f81f7990fb1b2e18080b6ca4744433
Image created
Evidence Examined
ALYSSA-PC-20150905-001215.rar
88f81f7990fb1b2e18080b6ca4744433
Image examined
Table 2: Evidence Verification Table


Other posts in this series
Volatility Memory Forensics - Investigation a potential virus situation - Part1
Volatility Memory Forensics - Investigation a potential virus situation - Part2
Volatility Memory Forensics - Investigation a potential virus situation - Part3
Volatility Memory Forensics - Investigation a potential virus situation - Part4
Volatility Memory Forensics - Investigation a potential virus situation - Part5