Sunday, April 13, 2014

Intrusion Detection ... it's is not only packet analysis

It's (log) analysis ... look at and for all traces of possible evidence

While being able to analyze packets is very important in detecting intrusions, it is not the only way of detecting intrusions.

To be able to properly analyze any intrusion event, the analyst must be prepared to look at data from any and or every possible source of information. Once a device is 'touched' evidence of this is more than likely somewhere to be found. Obviously, I'm assuming some type of logging is being done.

In this example, we will build out a scenario.

Let's start with the IDS.

The first trigger or alert, that there may be an intrusion will more than likely come from your IDS. You do have one right?! :-)

Once the IDS generates an alert, it is time to analyze that alert.

Evaluate the IDS rule against the packet which generated the event. Knowledge of your environment is assumed.

Does this look like a false positive? Example ... Is the attacker targeting a Linux Telnet Server while you are running Windows Telnet Sever?

Does this look like a true positive? Example ... Is the attacker targeting Windows Telnet Server while you are running Windows Telnet Server?

In our scenario, the IDS will generate an alert when "joe-attacker" successfully logs into the Telnet Server.

We will check ... ooops ... correlate the alert with the server logs to see what's available.

Let's put this together.

Using Snort as IDS and a Windows 2003 Telnet server, let's build this scenario out.

Configure two Snort variables

ipvar $HOME_NET # This would be the Windows Box running the Telnet Server. This is the system we wish to protect

ipvar $EXTERNAL_NET !$HOME_NET # Will be the Kali system on This says anything not defined as "$HOME_NET" should be considered hostile

Time to build a snort rule to identify when username 'joe-attacker' successfully logs in to our Windows Telnet server

This custom rule will go in the /etc/snort/rules/local.rules file

alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"Successful login from joe-attacker"; content:"Microsoft Telnet Server"; nocase; fast_pattern; content:"joe-attacker"; nocase; flow:from_server; Priority:1; classtype:successful-user; reference:url,; rev:1; sid:40000001)

Let's test snort to ensure there is no problem with this rule

root@security-nik:~# snort -c /etc/snort/snort.conf -T

Snort successfully validated the configuration!

Snort exiting

Looks good ... no problem with the rule

Now let's run snort to look for our traffic

root@security-nik:~/snort# snort -c /etc/snort/snort.conf -A full -i eth0 -q -l .

Time to verify Telnet Server is listening on the server

As netstat shows we are listening for Telnet traffic on port 23

C:\>netstat -anobp tcp

Active Connections

  Proto  Local Address          Foreign Address        State           PID

  TCP                 LISTENING       2164


Ok 'joe-attacker', it's time to logon and logout

root@security-nik:~# telnet -l joe-attacker


Connected to

Escape character is '^]'.

Welcome to Microsoft Telnet Service



Welcome to Microsoft Telnet Server.


C:\Documents and Settings\joe-attacker>exitConnection closed by foreign host.

The above shows "joe-attacker" successfully logged in, got a command prompt and then exited


Analysis time!!

Once again, let's start with the IDS.

here is what the IDS saw.

root@security-nik:~/snort# cat alert

[**] [1:40000001:1] Successful login from joe-attacker [**]

[Classification: Successful User Privilege Gain] [Priority: 1]

04/13-22:27:06.951742 ->

TCP TTL:128 TOS:0x0 ID:1503 IpLen:20 DgmLen:264 DF

***AP*** Seq: 0xC9A7854F  Ack: 0x1AE0887  Win: 0xFA6A  TcpLen: 32

TCP Options (3) => NOP NOP TS: 44372 1078019

[Xref =>]

Looks like "joe-attacker" successfully logged into the Telnet Server on 04/13 at 22:27:06 from host and source port 47018

Let's verify .... oooops correlate this with the windows logs. Please note, having accurate time information is critical for proper correlation. Your system(s) should be configured to sync their time with a at least 2 NTP Servers

The Windows logs shows the following

Event Type:        Success Audit

Event Source:    Security

Event Category:                Logon/Logoff

Event ID:              528

Date:                     4/13/2014

Time:                     10:27:06 PM

User:                     SECURITYNIK-2K3\joe-attacker

Computer:          SECURITYNIK-2K3


Successful Logon:

                User Name:        joe-attacker

                Domain:                               SECURITYNIK-2K3

                Logon ID:                             (0x0,0x5C116)

                Logon Type:       2

                Logon Process:  Advapi 

                Authentication Package:               Negotiate

                Workstation Name:        SECURITYNIK-2K3

                Logon GUID:      -

                Caller User Name:           LOCAL SERVICE

                Caller Domain:   NT AUTHORITY

                Caller Logon ID: (0x0,0x3E5)

                Caller Process ID: 3632

                Transited Services: -

                Source Network Address:            -

                Source Port:       -

As can be seen above "joe-attacker" successfully logged on 4/13/2014 at 10:27:06.

It would have been nice, if we also had the "Source Network Address". However, this information is not always available

Obviously there is other information in here. However, the objective is to show why logs and any or all other sources of information should be considered and correlated.

As shown above, traces and or evidence of an intrusion can be found in many different place. Take advantage of any logs or other sources of information you may have to help make your conclusion more sound.

Additional info on gathering and reading logs:

No comments:

Post a Comment