Wednesday, May 14, 2014

True or False? - Positive ... That is the question

Snort Alert:
[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