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 10.0.0.51/32 # 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
10.0.0.50/24. 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,security-nik.blogspot.com; 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 0.0.0.0:23 0.0.0.0:0 LISTENING 2164
[tlntsvr.exe]
Ok 'joe-attacker', it's time to logon and logout
root@security-nik:~# telnet -l joe-attacker 10.0.0.51
Trying 10.0.0.51...
Connected to 10.0.0.51.
Escape character is '^]'.
Welcome to Microsoft Telnet Service
password:
*===============================================================
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 10.0.0.51:23 -> 10.0.0.50:47018
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 => http://security-nik.blogspot.com]
Looks like "joe-attacker" successfully logged into
the Telnet Server on 04/13 at 22:27:06 from host 10.0.0.50 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
Description:
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:
http://httpd.apache.org/docs/current/logs.html
http://support.microsoft.com/kb/324091
Additional info on gathering and reading logs:
http://httpd.apache.org/docs/current/logs.html
http://support.microsoft.com/kb/324091
No comments:
Post a Comment