[119:2:1] http_inspect: DOUBLE DECODING ATTACK [Impact: Currently Not Vulnerable] From "ids.securitynik.lab" at Tue May 13 15:10:16 2014 UTC [Classification: Not Suspicious Traffic] [Priority: 3] {tcp} 10.0.0.100:34371->184.84.243.33:80
Recently a large number of the above alerts were seen rushing into an IDS. It was continuous which made the process of identifying the problem somewhat easier as opposed to having to look at historical data for something that happened in the past.
Beginning the investigative process
While looking at the IDS packet would be a great place to start, I choose not to. Why Not? I'm glad you asked :-).
The IDS would give me the packet which created the alert. Becuase this was ongoing, running wireshark on the affected system would give me the full communication. So, Wireshark was started to begin the capture.
As Wireshark was running a command prompt was opened and netstat was started with a refresh of 1 second. Below shows the output of the netstat output. By using the '-o' option, we will also see the PID of the process which is connecting to the IP in the destination.
C:\>netstat -no /t 1 | findstr /i 184.84.243.33
TCP 10.0.0.100:34209 184.84.243.33:80 TIME_WAIT 0
TCP 10.0.0.100:34304 184.84.243.33:80 ESTABLISHED 11776
TCP 10.0.0.100:34332 184.84.243.33:80 TIME_WAIT 0
TCP 10.0.0.100:34335 184.84.243.33:80 TIME_WAIT 0
TCP 10.0.0.100:34397 184.84.243.33:80 ESTABLISHED 11776
Once the Process ID was found, next step was to run tasklist on this
C:\>tasklist | findstr 11776
iexplore.exe 11776 RDP-Tcp#4 9 182,464 K
As can be seen tasklist suggested the process is iexplore.exe (Internet Explorer) and that this is a RDP (Terminal Server) Session with the user being on session #4 (RDP-Tcp#4)
Now that we have the user's RDP Session number, it is time to look directly at the Terminal Server to see what sessions exist and who this user is.
C:\>qwinsta
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
console 1 Conn
>rdp-tcp#1 User1 2 Active rdpwd
rdp-tcp#4 securityNik_User 9 Active rdpwd
rdp-tcp#6 User2 10 Active rdpwd
rdp-tcp 65536 Listen
As can be seen user "securityNik_User" is on session #4. But how can this be, the user is off from work.
Hmmmm!!!! Should I be worried? Let's find out.
Now that we have the user and the process, let's stop the packet capture to see what we can learn.
To keep things simple, let's use a display filter of "tcp.stream eq 0" and take a snapshot of what's there.
Client request:
GET /watch/video/shark-attacks-inflatable-boat/2gvvsys9k?from=en-ca-quad&cpkey=51b72330-00e2-4ff4-b67c-1d2cf1779465%257c%257c%257c%257c HTTP/1.1 Accept: text/html, application/xhtml+xml, */*
Referer: http://video.ca.msn.com/watch/video/inspiring-stories-about-mothers/2j6jhnvd?from=en-ca-quad&cpkey=51b72330-00e2-4ff4-b67c-1d2cf1779465%257c%257c%257c%257c
Accept-Language: en-us User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; WOW64; Trident/5.0) Accept-Encoding: gzip, deflate Host: video.ca.msn.com
Server Response
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.0
Content-Length: 36405
Looking at the above it would seem like the user was looking at videos from MSN and left his browser opened. As a result, once one video was finished another started playing automatically. This does not seem too dangerous or something that requires further investigation at this point. However, while this is my conclusion, a point I like to state is that the decision is always up to the analyst. Thus someone else may see something which I may have missed and this is why it is always best to work in teams and discuss these events before a conclusion is drawn.
Above I mentioned the user was off from work. However, it turned out the user's RDP session was still active because the user did not log out
Once the conclusion was drawn that this was not malicious, the next step was to close off user securityNik_User RDP Session.
As can be seen below, the user's session on longer exists.
C:\>qwinsta
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
console 1 Conn
>rdp-tcp#1 User1 2 Active rdpwd
rdp-tcp#6 User2 10 Active rdpwd
rdp-tcp 65536 Listen
Once the session was closed the alerts stopped occuring.
Considering the preceeding pargraphs, if this was considered to be malicious, it would have been time to begin analysing the IE session to see what other information can be gathered from it.
A point I like to keep repeating is obtaining as much information from as much different sources as possible, helps to make the conclusion drawn more sound and easier to stand up to scrutiny.
At the beginning I asked, True or False? I would say False.
Additional readings:
http://technet.microsoft.com/en-us/library/bb491010.aspx
http://technet.microsoft.com/en-us/library/cc730909.aspx
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/netstat.mspx?mfr=true
http://technet.microsoft.com/en-us/library/cc940097.aspx
http://www.scsssinc.bcentralhost.com/qw.htm
http://technet.microsoft.com/en-us/library/cc725766.aspx
No comments:
Post a Comment