In this first post, we will set 1 flag on each packet.
FIN -> Windows 2012/CentOS 6.5 -> 80 (Listening)
>>> sendp(Ether()/IP(src="10.0.0.100", dst=["10.0.0.50","10.0.0.101"])/TCP(sport=5000, dport=80, flags="F"),iface='eth0', count=1)..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
22 2.053441 10.0.0.50 -> 10.0.0.100 TCP 54 5000 > 80 [FIN] Seq=0 Win=8192 Len=0
23 2.054268 10.0.0.100 -> 10.0.0.50 TCP 60 80 > 5000 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
24 2.054747 10.0.0.50 -> 10.0.0.101 TCP 54 5000 > 80 [FIN] Seq=0 Win=8192 Len=0
From the above:
Windows 2012 - Packet with only FIN flag set, sent to LISTENING PORT, results in a RST-ACK
CentOS 6.5 - Packet with only FIN flag set, sent to a LISTENING PORT, results in a Silent Discard. That is there is no response from the TCP/IP Stack, the CentOS system simply drops the packet.
FIN -> Windows 2012/CentOS 6.5 -> 81 (Non-Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=81, flags="F"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))' 2 7.452878 10.0.0.50 -> 10.0.0.100 TCP 54 5000 > 81 [FIN] Seq=0 Win=8192 Len=0
5 7.454208 10.0.0.100 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
8 7.459747 10.0.0.50 -> 10.0.0.101 TCP 54 5000 > 81 [FIN] Seq=0 Win=8192 Len=0
11 7.460909 10.0.0.101 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
From the above:
Windows 2012 - Packet with only FIN flag set, sent to NON-LISTENING PORT, results in a RST-ACK
CentOS 6.5 - Packet with only FIN flag set, sent to NON-LISTENING PORT, results in a RST-ACK
---------------------------------------------------------------------------
SYN -> Windows 2012/CentOS 6.5 -> 80 (Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=80, flags="S"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
1 0.000000 10.0.0.50 -> 10.0.0.100 TCP 54 5000 > 80 [SYN] Seq=0 Win=8192 Len=0
4 0.001981 10.0.0.100 -> 10.0.0.50 TCP 60 80 > 5000 [SYN, ACK] Seq=3564399764 Ack=1 Win=8192 Len=0 MSS=1460
7 0.006482 10.0.0.50 -> 10.0.0.101 TCP 54 5000 > 80 [SYN] Seq=0 Win=8192 Len=0
8 0.007100 10.0.0.101 -> 10.0.0.50 TCP 60 80 > 5000 [SYN, ACK] Seq=1504198032 Ack=1 Win=14600 Len=0 MSS=1460
From the above:
Windows 2012 - Packet with only SYN flag set, sent to LISTENING PORT , results in a SYN-ACK
CentOS 6.5 - Packet with only SYN flag set, sent to LISTENING PORT , results in a SYN-ACK
SYN -> Windows 2012/CentOS 6.5 -> 81 (Non-Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=81, flags="S"),iface='eth0', count=1)..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
5 8.859239 10.0.0.50 -> 10.0.0.100 TCP 54 5000 > 81 [SYN] Seq=0 Win=8192 Len=0
8 8.860945 10.0.0.100 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
11 8.865713 10.0.0.50 -> 10.0.0.101 TCP 54 5000 > 81 [SYN] Seq=0 Win=8192 Len=0
12 8.866265 10.0.0.101 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
From the above:
Windows 2012 - Packet with only SYN flag set, sent to NON-LISTENING PORT, results in a RST-ACK
CentOS 6.5 - Packet with only SYN flag set, sent to NON-LISTENING PORT, results in a RST-ACK
---------------------------------------------------------------------------
RST -> Windows 2012/CentOS 6.5 -> 80 (Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=80, flags="R"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
1 0.000000 10.0.0.50 -> 10.0.0.100 TCP 54 5000 > 80 [RST] Seq=0 Win=8192 Len=0
4 0.006243 10.0.0.50 -> 10.0.0.101 TCP 54 5000 > 80 [RST] Seq=0 Win=8192 Len=0
From the above:
Windows 2012 - Packet with only RST flag set, sent to LISTENING PORT, results in a Silent Discard. That is there is no response from the TCP/IP Stack, the Windows 2012 system simply drops the packet.
CentOS 6.5 - Packet with only RST flag set, sent to LISTENING PORT, results in a Silent Discard. That is there is no response from the TCP/IP Stack, the CentOS system simply drops the packet.
RST -> Windows 2012/CentOS 6.5 -> 81 (Non-Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=81, flags="R"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
1 0.000000 10.0.0.50 -> 10.0.0.100 TCP 54 5000 > 81 [RST] Seq=0 Win=8192 Len=0
4 0.005582 10.0.0.50 -> 10.0.0.101 TCP 54 5000 > 81 [RST] Seq=0 Win=8192 Len=0
From the above:
Windows 2012 - Packet with only RST flag set, sent to LISTENING PORT, results in a Silent Discard. That is there is no response from the TCP/IP Stack, the Windows 2012 system simply drops the packet.
CentOS 6.5 - Packet with only RST flag set, sent to NON-LISTENING PORT, results in a Silent Discard. That is there is no response from the TCP/IP Stack, the CentOS system simply drops the packet.
---------------------------------------------------------------------------
ACK -> Windows 2012/CentOS 6.5 -> 80 (Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=80, flags="A"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
3 1.161009 10.0.0.50 -> 10.0.0.100 TCP 54 [TCP Window Update] 5000 > 80 [ACK] Seq=0 Ack=0 Win=8192 Len=0
6 1.162377 10.0.0.100 -> 10.0.0.50 TCP 60 80 > 5000 [RST] Seq=0 Win=0 Len=0
9 1.167634 10.0.0.50 -> 10.0.0.101 TCP 54 [TCP Window Update] 5000 > 80 [ACK] Seq=0 Ack=0 Win=8192 Len=0
12 1.170036 10.0.0.101 -> 10.0.0.50 TCP 60 80 > 5000 [RST] Seq=0 Win=0 Len=0
From the above:
Windows 2012 - Packet with only ACK flag set, sent to LISTENING PORT, results in a RST
CentOS 6.5 - Packet with only ACK flag set, sent to LISTENING PORT, results in a RST
ACK -> Windows 2012/CentOS 6.5 -> 81 (Non-Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=81, flags="A"),iface='eth0', count=1)
..
Sent 2 packets
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
1 0.000000 10.0.0.50 -> 10.0.0.100 TCP 54 [TCP Window Update] 5000 > 81 [ACK] Seq=0 Ack=0 Win=8192 Len=0
4 0.000896 10.0.0.100 -> 10.0.0.50 TCP 60 81 > 5000 [RST] Seq=0 Win=0 Len=0
7 0.006320 10.0.0.50 -> 10.0.0.101 TCP 54 [TCP Window Update] 5000 > 81 [ACK] Seq=0 Ack=0 Win=8192 Len=0
8 0.006949 10.0.0.101 -> 10.0.0.50 TCP 60 81 > 5000 [RST] Seq=0 Win=0 Len=0
From the above:
Windows 2012 - Packet with only ACK flag set, sent to a NON-LISTENING PORT, results in a RST
CentOS 6.5 - Packet with only ACK flag set, sent to a NON-LISTENING PORT, results in a RST
----------------------------------------------------------------------------
PSH -> Windows 2012/CentOS 6.5 -> 80 (Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=80, flags="P"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
1 0.000000 10.0.0.50 -> 10.0.0.100 TCP 54 [TCP Window Update] 5000 > 80 [PSH] Seq=0 Win=8192 Len=0
4 0.001861 10.0.0.100 -> 10.0.0.50 TCP 60 80 > 5000 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
7 0.006921 10.0.0.50 -> 10.0.0.101 TCP 54 [TCP Window Update] 5000 > 80 [PSH] Seq=0 Win=8192 Len=0
From the above:
Windows 2012 - Packet with only PSH flag set, sent to a LISTENING PORT, results in a RST-ACK
CentOS 6.5 - Packet with only PSH flag set, sent to a LISTENING PORT, results in a Silent Discard. That is there is no response from the TCP/IP Stack, the CentOS system simply drops the packet.
PSH -> Windows 2012/CentOS 6.5 -> 81 (Non-Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=81, flags="P"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
3 41.524627 10.0.0.50 -> 10.0.0.100 TCP 54 [TCP Window Update] 5000 > 81 [PSH] Seq=0 Win=8192 Len=0
6 41.527925 10.0.0.100 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
9 41.532888 10.0.0.50 -> 10.0.0.101 TCP 54 [TCP Window Update] 5000 > 81 [PSH] Seq=0 Win=8192 Len=0
10 41.533280 10.0.0.101 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
From the above:
Windows 2012 - Packet with only PSH flag set, sent to a NON-LISTENING PORT, results in a RST-ACK
CentOS 6.5 - Packet with only PSH flag set, sent to a NON-LISTENING PORT, results in a RST-ACK----------------------------------------------------------------------------
URG -> Windows 2012/CentOS 6.5 -> 80 (Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=80, flags="P"),iface='eth0', count=1)
..
Sent 2 packets
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
1 0.000000 10.0.0.50 -> 10.0.0.100 TCP 54 [TCP Window Update] 5000 > 80 [PSH] Seq=0 Win=8192 Len=0
4 0.003736 10.0.0.100 -> 10.0.0.50 TCP 60 80 > 5000 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
7 0.008091 10.0.0.50 -> 10.0.0.101 TCP 54 [TCP Window Update] 5000 > 80 [PSH] Seq=0 Win=8192 Len=0
From the above:
Windows 2012 - Packet with only URG flag set, sent to a LISTENING PORT, results in a RST-ACK
CentOS 6.5 - Packet with only URG flag set, sent to a LISTENING PORT, results in a Silent Discard. That is there is no response from the TCP/IP Stack, the CentOS system simply drops the packet.
URG -> Windows 2012/CentOS 6.5 -> 81 (Non-Listening)
>>> sendp(Ether()/IP(src="10.0.0.50", dst=["10.0.0.100","10.0.0.101"])/TCP(sport=5000, dport=81, flags="U"),iface='eth0', count=1)
..
Sent 2 packets.
root@securitynik:~# tshark -n -i eth0 -Y '((tcp.port==80) or (tcp.port==81))'
1 0.000000 10.0.0.50 -> 10.0.0.100 TCP 54 [TCP Window Update] 5000 > 81 [URG] Seq=0 Win=8192 Urg=0 Len=0
2 0.000598 10.0.0.100 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
3 0.001072 10.0.0.50 -> 10.0.0.101 TCP 54 [TCP Window Update] 5000 > 81 [URG] Seq=0 Win=8192 Urg=0 Len=0
4 0.001492 10.0.0.101 -> 10.0.0.50 TCP 60 81 > 5000 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0
From the above:
Windows 2012 - Packet with only URG flag set, sent to a NON-LISTENING PORT, results in a RST-ACK
CentOS 6.5 - Packet with only URG flag set, sent to a NON-LISTENING PORT, results in a RST-ACK
If you wish to have this as a reference, you may download:
"Stimulus and Response.pdf" document.
md5:8c931888caf948504188f57440396ebc
sha-1:c4cb5b06928e660a09ddc7eaf4b7e32fb0dd1a27
stimulus-response.xlsx
MD5:6176b65c89b73e3b07a519bf77db462a
SHA-1:1ff6308e2a56a1c950e4cc5831932d78563bf853
Sunday, July 6, 2014
Stimulus and Response - TCP
So there I was, after encountering some flow data with strange flags, I decided to do a post on stimulus and response. Little did I know, I was biting off a lot more than I would have liked to chew. Just as I was about to finish up, a colleague (thanks Abdul) mentioned, since I'm currently looking at sending these packets to a Windows box to determine the response, I should also send them to a Linux box to get its response. So just when I thought I was about to finish, I just had to basically restart.
Considering the above, I must say I'm glad I got the suggestion. As a result of that suggestion, I've recognize that there are truly significant differences between the ways the Windows 2012 and the CentOS 6.5 TCP/IP stacks handle these packets.
It is common knowledge that when we send a SYN packet to a listening port, we expect a SYN-ACK. Likewise, when we send a SYN to non listening port, we should get back a RST-ACK. However, what happens when we send an ACK or RST or some strange combination to either a listening or a non-listening port? These are the questions we will answer in this series.
This series of posts will be based on sending crafted packets (the stimulus) with various flags set to see the type of responses.
The tests will involve setting specific flags or combination of these flags to a Windows 2012 and CentOS 6.5 systems, both with their firewalls off.
We will test the response when the port (80) is listening and the other when the port (81) is not listening
Topology
SIFT - 10.0.0.50
Windows2012 - 10.0.0.100
CentOS 6.5 - 10.0.0.101
Tool for analysis:
tshark
Packet Crafting:
scapy
The following will be used: flag(s) -> system/system -> port
For a SYN flag to Windows 2012 host / CentOS 6.5 on port 80, we would have: SYN -> Windows 2012/CentOS 6.5 -> 80
To ensure the system where the packet is being crafted does not respond to any unknown packets, we will prevent it from sending out RST by using the following iptables rule:
iptables -A OUTPUT -p tcp -m tcp --tcp-flags RST RST -j DROP
So without further ado, let's look at the next post to get started
If you wish to have this as a reference, you may download:
"Stimulus and Response.pdf" document.
md5:8c931888caf948504188f57440396ebc
sha-1:c4cb5b06928e660a09ddc7eaf4b7e32fb0dd1a27
stimulus-response.xlsx
MD5:6176b65c89b73e3b07a519bf77db462a
SHA-1:1ff6308e2a56a1c950e4cc5831932d78563bf853
Reference and Additional Readings:
http://newartisans.com/2007/09/neat-tricks-with-iptables/
Considering the above, I must say I'm glad I got the suggestion. As a result of that suggestion, I've recognize that there are truly significant differences between the ways the Windows 2012 and the CentOS 6.5 TCP/IP stacks handle these packets.
It is common knowledge that when we send a SYN packet to a listening port, we expect a SYN-ACK. Likewise, when we send a SYN to non listening port, we should get back a RST-ACK. However, what happens when we send an ACK or RST or some strange combination to either a listening or a non-listening port? These are the questions we will answer in this series.
This series of posts will be based on sending crafted packets (the stimulus) with various flags set to see the type of responses.
The tests will involve setting specific flags or combination of these flags to a Windows 2012 and CentOS 6.5 systems, both with their firewalls off.
We will test the response when the port (80) is listening and the other when the port (81) is not listening
Topology
SIFT - 10.0.0.50
Windows2012 - 10.0.0.100
CentOS 6.5 - 10.0.0.101
Tool for analysis:
tshark
Packet Crafting:
scapy
The following will be used: flag(s) -> system/system -> port
For a SYN flag to Windows 2012 host / CentOS 6.5 on port 80, we would have: SYN -> Windows 2012/CentOS 6.5 -> 80
To ensure the system where the packet is being crafted does not respond to any unknown packets, we will prevent it from sending out RST by using the following iptables rule:
iptables -A OUTPUT -p tcp -m tcp --tcp-flags RST RST -j DROP
So without further ado, let's look at the next post to get started
If you wish to have this as a reference, you may download:
"Stimulus and Response.pdf" document.
md5:8c931888caf948504188f57440396ebc
sha-1:c4cb5b06928e660a09ddc7eaf4b7e32fb0dd1a27
stimulus-response.xlsx
MD5:6176b65c89b73e3b07a519bf77db462a
SHA-1:1ff6308e2a56a1c950e4cc5831932d78563bf853
Reference and Additional Readings:
http://newartisans.com/2007/09/neat-tricks-with-iptables/
Sunday, June 15, 2014
Beginning Memory Forensics - Volatility
In the previous post, the memory image of a Windows 2003SP2 machine was dumped. Now that we have the memory image, let's use volatility to analyze its contents.
First, let look at the memory image to see what OS volatility thinks it may be. Do remember, I already stated this is a Windows2003SP2 but let's see what volatilty says.
To identify the image, we use following volatility command.
./vol.py -f SECURITYNIK-SRV-20140613-015002.raw imageinfo
As can be seen above, the imageinfo plugin gave us some suggested profiles. From the additional information, we can see we also have the time the image was aquired. We will also use the KDBG address information as we continue to analyze our image.
Let's move on to the connections plugin to see what network connections may have been established at the time this memory image was acquired.
To find the network connections we use:
./vol.py -f SECURITYNIK-SRV-20140613-015002.raw connections
There seems to have been a connection from the localhost on port 1033 to host 192.168.0.15 on port 4444. We also see this connection reports it was using PID 4712.
Let's look at the process tree to see what we can find using command:
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw pstree
Name Pid PPid Thds Hnds Time
0x812923e8:rundll32.exe 4712 4700 2 35 2014-06-13 01:49:51 UTC+0000
. 0x81292b70:cmd.exe 4728 4712 1 30 2014-06-13 01:49:51 UTC+0000
It seems process 4712 also had a child process with PID 4728 (cmd.exe). From this perspective, I would say someone at IP 192.168.0.15 had access to the command prompt. We also see that process 4712 parent is reported as PID 4700.
Let's see what we can learn about PID 4700
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw pslist --pid=4700
Hmmmmmm!! This is strange, PID 4700 does not seem to exist.
Let's move on. What privileges was PID 4712 (rundll32.exe) and PID 4728 (cmd.exe) running with? Let's find out.
From the above, it seems these 2 processes were also running with Local System and Administrator privileges.
Since, were unable to find anything relating to PID 4700, let's see what DLLs may be in use by PID 4712 (rundll32.exe)
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw dlllist -p 4712
... and now for PID 4728 (cmd.exe)
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw dlllist -p 4728
Let's go back to process rundll32.dll (PID 4712) and see if there may be any malware in there.
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw malfind -p 4712 --dump-dir /tmp
The above command created the file process.0x812923e8.0x90000.dmp in the /tmp directory
Let's post this file up to virustotal and see what we get.
Looks like the file was detected as containing malware by 2 out of the 54 AV engines.
As the above shows, we can use tools like volatility to analyze the contents of memory to draw conclusions.
Reference and Additional Readings:
https://code.google.com/p/volatility/wiki/CommandReference
http://moyix.blogspot.ca/2008/04/finding-kernel-global-variables-in.html
https://www.virustotal.com/
First, let look at the memory image to see what OS volatility thinks it may be. Do remember, I already stated this is a Windows2003SP2 but let's see what volatilty says.
To identify the image, we use following volatility command.
./vol.py -f SECURITYNIK-SRV-20140613-015002.raw imageinfo
As can be seen above, the imageinfo plugin gave us some suggested profiles. From the additional information, we can see we also have the time the image was aquired. We will also use the KDBG address information as we continue to analyze our image.
Let's move on to the connections plugin to see what network connections may have been established at the time this memory image was acquired.
To find the network connections we use:
./vol.py -f SECURITYNIK-SRV-20140613-015002.raw connections
There seems to have been a connection from the localhost on port 1033 to host 192.168.0.15 on port 4444. We also see this connection reports it was using PID 4712.
Let's look at the process tree to see what we can find using command:
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw pstree
Name Pid PPid Thds Hnds Time
0x812923e8:rundll32.exe 4712 4700 2 35 2014-06-13 01:49:51 UTC+0000
. 0x81292b70:cmd.exe 4728 4712 1 30 2014-06-13 01:49:51 UTC+0000
It seems process 4712 also had a child process with PID 4728 (cmd.exe). From this perspective, I would say someone at IP 192.168.0.15 had access to the command prompt. We also see that process 4712 parent is reported as PID 4700.
Let's see what we can learn about PID 4700
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw pslist --pid=4700
Hmmmmmm!! This is strange, PID 4700 does not seem to exist.
Let's move on. What privileges was PID 4712 (rundll32.exe) and PID 4728 (cmd.exe) running with? Let's find out.
From the above, it seems these 2 processes were also running with Local System and Administrator privileges.
Since, were unable to find anything relating to PID 4700, let's see what DLLs may be in use by PID 4712 (rundll32.exe)
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw dlllist -p 4712
... and now for PID 4728 (cmd.exe)
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw dlllist -p 4728
Let's go back to process rundll32.dll (PID 4712) and see if there may be any malware in there.
vol.py --profile=Win2003SP2x86 --kdbg=0x808993d8 -f SECURITYNIK-SRV-20140613-015002.raw malfind -p 4712 --dump-dir /tmp
The above command created the file process.0x812923e8.0x90000.dmp in the /tmp directory
Let's post this file up to virustotal and see what we get.
Looks like the file was detected as containing malware by 2 out of the 54 AV engines.
As the above shows, we can use tools like volatility to analyze the contents of memory to draw conclusions.
Reference and Additional Readings:
https://code.google.com/p/volatility/wiki/CommandReference
http://moyix.blogspot.ca/2008/04/finding-kernel-global-variables-in.html
https://www.virustotal.com/
Saturday, June 14, 2014
Beginning Memory Forensics – Getting the contents of RAM - DumpIT
Why would we want to do memory Forensics?
As I’ve said previously, in analyzing an intrusion or any signs that there may have been an intrusion, the more data we have the better. This data can be from the IDS/IPS, log sources, etc. One area we should not exclude is the memory of the device we are investigating. Using only the log sources and IDS alert, it is unlikely we will get a full picture of all the processes, listening and or established network connections, etc.
In this post we focus on getting the contents of a Windows 2003SP2 system using DumpIT. According to the description from the moonsols.com website "This utility is used to generate a physical memory dump of Windows machines. It works with both x86 (32-bits) and x64 (64-bits) machines"
So without further ado, lets DumpIT.
Using this tool is super easy, all you do is run the executable and it creates the image in the directory from which the executable was run. The file name is a combination of computer name, date and a final number of which I'm not sure what it is at this time. The extension of the file is ".raw" Eg. of the filename is "SECURITYNIK-SRV-20140613-015002.raw"
As can be seen above, first we executed "dumpit".
The second step in the process is to press "Y" or "N" if you would like to continue. Once you pressed "Y", the process runs and once completed successfully, you will see "Success"
That's it. Next post we will use Volatility to analyze the the memory.
References and Additional Readings:
http://www.moonsols.com/resources/
As I’ve said previously, in analyzing an intrusion or any signs that there may have been an intrusion, the more data we have the better. This data can be from the IDS/IPS, log sources, etc. One area we should not exclude is the memory of the device we are investigating. Using only the log sources and IDS alert, it is unlikely we will get a full picture of all the processes, listening and or established network connections, etc.
In this post we focus on getting the contents of a Windows 2003SP2 system using DumpIT. According to the description from the moonsols.com website "This utility is used to generate a physical memory dump of Windows machines. It works with both x86 (32-bits) and x64 (64-bits) machines"
So without further ado, lets DumpIT.
Using this tool is super easy, all you do is run the executable and it creates the image in the directory from which the executable was run. The file name is a combination of computer name, date and a final number of which I'm not sure what it is at this time. The extension of the file is ".raw" Eg. of the filename is "SECURITYNIK-SRV-20140613-015002.raw"
As can be seen above, first we executed "dumpit".
The second step in the process is to press "Y" or "N" if you would like to continue. Once you pressed "Y", the process runs and once completed successfully, you will see "Success"
That's it. Next post we will use Volatility to analyze the the memory.
References and Additional Readings:
http://www.moonsols.com/resources/
Thursday, June 12, 2014
snort rules - Pandemiya Trojan - Zeus-based Variant - Revision 2
After some discussion it was recognised that the string which was being searched for in the URI may be randomly generated. It was suggested that "User-Agent: Hello 2.0" should be unique enough to capture any usage of this Zeus variant. As a result, I'm releasing Revision 2 of the rules. These two rules should capture any GET or POST request made from the variant leaving the "$HOME" network.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Va riant - POST request"; content:"POST"; http_method; nocase; content:"User|2D|Agent|3A 20|Hello|20|2|2E|0"; http_header; nocase; Priority: 1; Rev: 2; sid:4000001; reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Variant - GET request"; content:"GET"; http_method; nocase; content:"User|2D|Agent|3A 20|Hello|20|2|2E|0"; http_header; nocase; Priority: 1; Rev: 2; sid:4000002; reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Va riant - POST request"; content:"POST"; http_method; nocase; content:"User|2D|Agent|3A 20|Hello|20|2|2E|0"; http_header; nocase; Priority: 1; Rev: 2; sid:4000001; reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya Trojan - Zeus-based Variant - GET request"; content:"GET"; http_method; nocase; content:"User|2D|Agent|3A 20|Hello|20|2|2E|0"; http_header; nocase; Priority: 1; Rev: 2; sid:4000002; reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants)
Wednesday, June 11, 2014
snort rules - Pandemiya Trojan - Zeus-based Variant
Earlier today a colleague (thanks Zuhair) made me aware of a new Zeus-based variant which was discovered. He sent me the following three links:
High-level Description
High-level Description
Detailed Technical Description
Symantec Assessment
As a result I've developed and tested the following snort rules. I'm publishing them here in the hope that they can help someone. I will be implementing these and thought someone else may find them useful.
alert
tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya
Trojan - Zeus-based Variant - POST request"; flow:to_server,established;
content:"POST";
http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0";
nocase;fast_pattern;content:"aWnBrokeQxPeKunljEDkm"; nocase;
Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2
;sid:4000001)
alert
tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya
Trojan - Zeus-based Variant - POST request"; flow:to_server,established;
content:"POST";
http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0";
nocase;fast_pattern;content:"P4ND3M1CB00BF4C3"; nocase;
Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2
;sid:4000001)
alert
tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya
Trojan - Zeus-based Variant - GET request"; flow:to_server,established;
content:"GET";
http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0";
nocase;fast_pattern;content:"aWnBrokeQxPeKunljEDkm"; nocase;
Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2
;sid:4000001)
alert
tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Pandemiya
Trojan - Zeus-based Variant - GET request"; flow:to_server,established;
content:"GET";
http_method; content:"User-Agent";nocase; content:"Hello|20|2|2E|0";
nocase;fast_pattern;content:"P4ND3M1CB00BF4C3"; nocase;
Priority:1;reference:url,blogs.rsa.com/new-pandemiya-trojan-emerges-alternative-zeus-based-variants,symantec.com/security_response/writeup.jsp?docid=2014-061111-3458-99&tabid=2
;sid:4000001)
If anyone thinks these can be better modified,please feel free to drop me a line at nikalleyne at gmail dot com.
Sunday, June 8, 2014
Beginning IPv6 - Analyzing FTP Traffic
In the previous post we look at analyzing Telnet. Let's now look at the FTP protocol. Since in the post on DNS I elaborated on the fields which makes up the header of the IPv6 protocol, I will refrain from doing so again. Some information missing in this post may be found it earlier posts in this series
root@securitynik:~/securitynik#tshark -r ipv6-ftp.pcap -n -c 3
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 53024 > 21 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=303844 TSecr=0 WS=128
2 0.001874 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 21 > 53024 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=102405 TSecr=303844
3 0.001921 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 53024 > 21 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=303845 TSecr=102405
The 3 packets above represents the typical TCP 3-Way handshake. Nothing here different from what we would have seen in our IPv4 TCP 3-way handshake
4 0.024868 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 FTP 113 Response: 220 Microsoft FTP Service
In packet 4 above we see the server at source "fd33:e581:65d4:0:a000:27ff:fe21:1a75" sending its FTP banner
5 0.025134 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 53024 > 21 [ACK] Seq=1 Ack=28 Win=28800 Len=0 TSval=303850 TSecr=102406
In packet 5 above we see the client at "fd33:e581:65d4:0:a000:27ff:fe28:1d5" acknowledges the server's communication.
Once again, let's cut through the clutter and see what we get from the TCP stream 0
root@securitynik:~/securitynik# tshark -r ipv6-ftp.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:21
Node 1: 253.51.229.129:53024
27
220 Microsoft FTP Service
20
USER administrator
23
331 Password required
15
PASS Testing1
21
230 User logged in.
6
SYST
16
215 Windows_NT
52
EPRT |2|fd33:e581:65d4:0:a000:27ff:fe28:1d5|49829|
30
200 EPRT command successful.
6
LIST
54
125 Data connection already open; Transfer starting.
24
226 Transfer complete.
5
PWD
31
257 "/" is current directory.
6
QUIT
14
221 Goodbye.
As can be seen above, the knowledge we have from analyzing FTP on IPv4 can be easily transferable to IPv6
This ends this series on beginning IPv6. If you think there is something I missed, stated incorrectly or just needed further elaboration, please feel free to leave a comment.
root@securitynik:~/securitynik#tshark -r ipv6-ftp.pcap -n -c 3
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 53024 > 21 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=303844 TSecr=0 WS=128
2 0.001874 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 21 > 53024 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=102405 TSecr=303844
3 0.001921 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 53024 > 21 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=303845 TSecr=102405
The 3 packets above represents the typical TCP 3-Way handshake. Nothing here different from what we would have seen in our IPv4 TCP 3-way handshake
4 0.024868 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 FTP 113 Response: 220 Microsoft FTP Service
In packet 4 above we see the server at source "fd33:e581:65d4:0:a000:27ff:fe21:1a75" sending its FTP banner
5 0.025134 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 53024 > 21 [ACK] Seq=1 Ack=28 Win=28800 Len=0 TSval=303850 TSecr=102406
In packet 5 above we see the client at "fd33:e581:65d4:0:a000:27ff:fe28:1d5" acknowledges the server's communication.
Once again, let's cut through the clutter and see what we get from the TCP stream 0
root@securitynik:~/securitynik# tshark -r ipv6-ftp.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:21
Node 1: 253.51.229.129:53024
27
220 Microsoft FTP Service
20
USER administrator
23
331 Password required
15
PASS Testing1
21
230 User logged in.
6
SYST
16
215 Windows_NT
52
EPRT |2|fd33:e581:65d4:0:a000:27ff:fe28:1d5|49829|
30
200 EPRT command successful.
6
LIST
54
125 Data connection already open; Transfer starting.
24
226 Transfer complete.
5
PWD
31
257 "/" is current directory.
6
QUIT
14
221 Goodbye.
As can be seen above, the knowledge we have from analyzing FTP on IPv4 can be easily transferable to IPv6
This ends this series on beginning IPv6. If you think there is something I missed, stated incorrectly or just needed further elaboration, please feel free to leave a comment.
Beginning IPv6 - Analyzing Telnet Traffic
In the previous post we look at analyzing HTTP. Let's now look at the Telnet protocol. Since in the post on DNS I elaborated on the fields which makes up the header of the IPv6 protocol, I will refrain from doing so again. In addition, as we continue to go through these protocols, we will omit stuff which can be easily found in the previous posts in this series.
root@securitynik:~/securitynik# tshark -r ipv6-telnet.pcap -n -c 3
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 46906 > 23 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=283731 TSecr=0 WS=128
2 0.002348 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 23 > 46906 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=94364 TSecr=283731
3 0.002402 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 46906 > 23 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=283732 TSecr=94364
The 3 packets above represents the typical TCP 3-Way handshake. Nothing here different is from what we would have seen in our IPv4 TCP 3-way handshake
4 0.004552 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TELNET 113 Telnet Data ...
In packet 4 above we see the client at source "fd33:e581:65d4:0:a000:27ff:fe28:1d5" beginning its Telnet Session
5 0.048954 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 86 23 > 46906 [ACK] Seq=1 Ack=28 Win=65536 Len=0 TSval=94369 TSecr=283732
Here we see the server at "fd33:e581:65d4:0:a000:27ff:fe21:1a75" responding with an ACK (Acknowledgement) to the request sent by the client.
Ok, let's skip through some of the clutter and follow TCP stream 0
root@securitynik:~/securitynik#tshark -r ipv6-telnet.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:46906
Node 1: 253.51.229.129:23
27
........... ..!.."..'.....#
21
..%........'.........
21
..%.......P..........
53
..... ..!.."..'.....'..SFUTLNTVER.SFUTLNTMODE.......#
38
Welcome to Microsoft Telnet Service
34
..'..DISPLAY.securitynik:0....'...
9
login:
password:
...... REDUCED FOR BREVITY ........
*===============================================================
Microsoft Telnet Server.
*===============================================================
C:\Users\Administrator>
1
As can be seen above, the knowledge we have from analyzing Telnet on IPv4 can be easily transferred to IPv6
root@securitynik:~/securitynik# tshark -r ipv6-telnet.pcap -n -c 3
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 46906 > 23 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=283731 TSecr=0 WS=128
2 0.002348 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 23 > 46906 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=94364 TSecr=283731
3 0.002402 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 46906 > 23 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=283732 TSecr=94364
The 3 packets above represents the typical TCP 3-Way handshake. Nothing here different is from what we would have seen in our IPv4 TCP 3-way handshake
4 0.004552 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TELNET 113 Telnet Data ...
In packet 4 above we see the client at source "fd33:e581:65d4:0:a000:27ff:fe28:1d5" beginning its Telnet Session
5 0.048954 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 86 23 > 46906 [ACK] Seq=1 Ack=28 Win=65536 Len=0 TSval=94369 TSecr=283732
Here we see the server at "fd33:e581:65d4:0:a000:27ff:fe21:1a75" responding with an ACK (Acknowledgement) to the request sent by the client.
Ok, let's skip through some of the clutter and follow TCP stream 0
root@securitynik:~/securitynik#tshark -r ipv6-telnet.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:46906
Node 1: 253.51.229.129:23
27
........... ..!.."..'.....#
21
..%........'.........
21
..%.......P..........
53
..... ..!.."..'.....'..SFUTLNTVER.SFUTLNTMODE.......#
38
Welcome to Microsoft Telnet Service
34
..'..DISPLAY.securitynik:0....'...
9
login:
password:
...... REDUCED FOR BREVITY ........
*===============================================================
Microsoft Telnet Server.
*===============================================================
C:\Users\Administrator>
1
As can be seen above, the knowledge we have from analyzing Telnet on IPv4 can be easily transferred to IPv6
Beginning IPv6 - Analyzing HTTP traffic
In the previous post we looked at analyzing DNS. Let's now look at the HTTP protocol. Since in the post on DNS I elaborated on the fileds which makes up the header of the IPv6 protocol, I will refrain from doing so again.
Let's use our IPv4 TCP knowledge to analyze this IPv6 communication
Let's run tshark against our capture
root@securitynik:~/securitynik# tshark -r ipv6-http.pcap -n -c 3
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 55594 > 80 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=265480 TSecr=0 WS=128
2 0.001162 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 80 > 55594 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=87067 TSecr=265480
3 0.001220 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 55594 > 80 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=265480 TSecr=87067
The 3 packets above represents the typical TCP 3-Way handshake. Nothing here is different from what we would have seen in our IPv4 TCP 3-way handshake
4 0.001807 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 HTTP 370 GET / HTTP/1.1
In packet 4 above we see the client at source "fd33:e581:65d4:0:a000:27ff:fe28:1d5" do a GET request for /
5 0.050772 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 86 80 > 55594 [ACK] Seq=1 Ack=285 Win=65536 Len=0 TSval=87072 TSecr=265480
Here we see the server at "fd33:e581:65d4:0:a000:27ff:fe21:1a75" responding with an ACK (Acknowledgement) to the request sent by the client.
8 0.565480 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 HTTP 281 HTTP/1.1 200 OK (text/html)
In packet 8, we see the server responds with a Status Code of 200
Ok, let's skip through some of the clutter and follow TCP stream 0
root@securitynik:~/securitynik# tshark -r ipv6-http.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:55594
Node 1: 253.51.229.129:80
284
GET / HTTP/1.1
Host: websrv
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
1428
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Thu, 05 Jun 2014 02:42:28 GMT
Accept-Ranges: bytes
ETag: "55a1baca6780cf1:0"
Server: Microsoft-IIS/8.0
Date: Fri, 06 Jun 2014 03:09:18 GMT
Content-Length: 1398
............. reduced for brevity .........
As can be seen above, the knowledge we have from analyzing HTTP on IPv4 can be easily transferred to IPv6
Let's use our IPv4 TCP knowledge to analyze this IPv6 communication
Let's run tshark against our capture
root@securitynik:~/securitynik# tshark -r ipv6-http.pcap -n -c 3
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 94 55594 > 80 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=265480 TSecr=0 WS=128
2 0.001162 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 94 80 > 55594 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1440 WS=256 SACK_PERM=1 TSval=87067 TSecr=265480
3 0.001220 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 TCP 86 55594 > 80 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=265480 TSecr=87067
The 3 packets above represents the typical TCP 3-Way handshake. Nothing here is different from what we would have seen in our IPv4 TCP 3-way handshake
4 0.001807 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 HTTP 370 GET / HTTP/1.1
In packet 4 above we see the client at source "fd33:e581:65d4:0:a000:27ff:fe28:1d5" do a GET request for /
5 0.050772 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 TCP 86 80 > 55594 [ACK] Seq=1 Ack=285 Win=65536 Len=0 TSval=87072 TSecr=265480
Here we see the server at "fd33:e581:65d4:0:a000:27ff:fe21:1a75" responding with an ACK (Acknowledgement) to the request sent by the client.
8 0.565480 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 HTTP 281 HTTP/1.1 200 OK (text/html)
In packet 8, we see the server responds with a Status Code of 200
Ok, let's skip through some of the clutter and follow TCP stream 0
root@securitynik:~/securitynik# tshark -r ipv6-http.pcap -z "follow,tcp,ascii,0" | more
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 253.51.229.129:55594
Node 1: 253.51.229.129:80
284
GET / HTTP/1.1
Host: websrv
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
1428
HTTP/1.1 200 OK
Content-Type: text/html
Last-Modified: Thu, 05 Jun 2014 02:42:28 GMT
Accept-Ranges: bytes
ETag: "55a1baca6780cf1:0"
Server: Microsoft-IIS/8.0
Date: Fri, 06 Jun 2014 03:09:18 GMT
Content-Length: 1398
............. reduced for brevity .........
As can be seen above, the knowledge we have from analyzing HTTP on IPv4 can be easily transferred to IPv6
Beginning IPv6 - Analyzing DNS
Now we move into the meat of the matter. All the previous posts were really preparing for this stage. It is obvious that, unless we understand the IPv6 header and the components within it, it would be extremely difficult for us to analyze any type of communication running on top of IPv6.
One of the things we will learn as we move through these next few posts is, the knowledge we have of analyzing IPv4 application layer, is easily transferable to IPv6 application layer protocols. Basically not much has change if anything in most cases.
So without further ado, let's look at the DNS protocol.
The following represents the configuration of our local DNS resolver.
root@securitynik:~/securitynik# cat /etc/resolv.conf
nameserver fd33:e581:65d4:0:a000:27ff:fe21:1a75
Now let's run tshark against our packet capture.
root@securitynik:~/securitynik#tshark -n -r ipv6-dns-success.pcap
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 DNS 95 Standard query 0x537b AAAA securitynik.lab
2 0.000613 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 DNS 123 Standard query response 0x537b AAAA fd33:e581:65d4:0:a000:27ff:fe21:1a75
So above we see we have two packets. The first represents the DNS query over IPv6 and the second represents the DNS response.
Digging deeper - Ignoring time information!
Packet 1:
fd33:e581:65d4:0:a000:27ff:fe28:1d5 - represents the source IP or the device where the traffic originated.
fd33:e581:65d4:0:a000:27ff:fe21:1a75 - represents the destination or the device to which the traffic is being sent
DNS - Similary to IPv4 this represents the DNS protocol and would be seen in the "Next Header" portion of the IPv6 header
95 - total size of the packet
By default tshark gives us the entire packet size which in this case we see 95 bytes. However, what we should be more concerned about here is the "Payload Length". To find the "Payload Length" we subtract the length of the Ethernet header (14 bytes) and the length of the IPv6 Header (40) bytes from the total 95 bytes.
95 - (14 + 40) = 41
So it would be clear to see that our Payload length is 41 bytes
Standard query - this is a DNS Query
0x537b - Query ID
AAAA - Record type. In IPv4. This would have more than likely been an 'A' record
securitynik.lab - this is the domain which was requested
Packet 2:
This represents the response to packet 1
fd33:e581:65d4:0:a000:27ff:fe21:1a75 - In packet 1 this was the destination to which we sent the DNS request. In packet 2, we now have the DNS server responding
fd33:e581:65d4:0:a000:27ff:fe28:1d5 - The response is now coming back to our client IP.
DNS - Next Header which represents DNS
123 - Total size of the packet
Once again, we are interested in the Payload Length. To find this value we use the same formula as we did in packet 1. Subtract the Ethernet header (14 bytes) and the IPv6 header (40) bytes from 123.
123 - (14 + 40) = 69 bytes
Standard query response - Response to our original request
0x537b - How do we know this response is for our original packet? The Query ID in both packets matches
AAAA fd33:e581:65d4:0:a000:27ff:fe21:1a75 - basically stating that our requested domain - securitynik.lab is at the address
As can be seen, there is not that much difference between the way DNS operates in IPv4 than it does it IPv6
One of the things we will learn as we move through these next few posts is, the knowledge we have of analyzing IPv4 application layer, is easily transferable to IPv6 application layer protocols. Basically not much has change if anything in most cases.
So without further ado, let's look at the DNS protocol.
The following represents the configuration of our local DNS resolver.
root@securitynik:~/securitynik# cat /etc/resolv.conf
nameserver fd33:e581:65d4:0:a000:27ff:fe21:1a75
Now let's run tshark against our packet capture.
root@securitynik:~/securitynik#tshark -n -r ipv6-dns-success.pcap
1 0.000000 fd33:e581:65d4:0:a000:27ff:fe28:1d5 -> fd33:e581:65d4:0:a000:27ff:fe21:1a75 DNS 95 Standard query 0x537b AAAA securitynik.lab
2 0.000613 fd33:e581:65d4:0:a000:27ff:fe21:1a75 -> fd33:e581:65d4:0:a000:27ff:fe28:1d5 DNS 123 Standard query response 0x537b AAAA fd33:e581:65d4:0:a000:27ff:fe21:1a75
So above we see we have two packets. The first represents the DNS query over IPv6 and the second represents the DNS response.
Digging deeper - Ignoring time information!
Packet 1:
fd33:e581:65d4:0:a000:27ff:fe28:1d5 - represents the source IP or the device where the traffic originated.
fd33:e581:65d4:0:a000:27ff:fe21:1a75 - represents the destination or the device to which the traffic is being sent
DNS - Similary to IPv4 this represents the DNS protocol and would be seen in the "Next Header" portion of the IPv6 header
95 - total size of the packet
By default tshark gives us the entire packet size which in this case we see 95 bytes. However, what we should be more concerned about here is the "Payload Length". To find the "Payload Length" we subtract the length of the Ethernet header (14 bytes) and the length of the IPv6 Header (40) bytes from the total 95 bytes.
95 - (14 + 40) = 41
So it would be clear to see that our Payload length is 41 bytes
Standard query - this is a DNS Query
0x537b - Query ID
AAAA - Record type. In IPv4. This would have more than likely been an 'A' record
securitynik.lab - this is the domain which was requested
Packet 2:
This represents the response to packet 1
fd33:e581:65d4:0:a000:27ff:fe21:1a75 - In packet 1 this was the destination to which we sent the DNS request. In packet 2, we now have the DNS server responding
fd33:e581:65d4:0:a000:27ff:fe28:1d5 - The response is now coming back to our client IP.
DNS - Next Header which represents DNS
123 - Total size of the packet
Once again, we are interested in the Payload Length. To find this value we use the same formula as we did in packet 1. Subtract the Ethernet header (14 bytes) and the IPv6 header (40) bytes from 123.
123 - (14 + 40) = 69 bytes
Standard query response - Response to our original request
0x537b - How do we know this response is for our original packet? The Query ID in both packets matches
AAAA fd33:e581:65d4:0:a000:27ff:fe21:1a75 - basically stating that our requested domain - securitynik.lab is at the address
As can be seen, there is not that much difference between the way DNS operates in IPv4 than it does it IPv6
Subscribe to:
Posts (Atom)