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
Thursday, December 10, 2015
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
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
Additional Materials
https://www.comparitech.com/net-admin/tcpdump-cheat-sheet/
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
Additional Materials
https://www.comparitech.com/net-admin/tcpdump-cheat-sheet/
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
Additional Materials
https://www.comparitech.com/net-admin/tcpdump-cheat-sheet/
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
Additional Materials
https://www.comparitech.com/net-admin/tcpdump-cheat-sheet/
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
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
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
Subscribe to:
Posts (Atom)