- What trends did you identify?
RPC and FTP
services are popular amongst attackers.
Numerous ftp and rpc scans were used to
identify available services on the victim hosts. Scans for RPC services are often followed by
RPC info queries. In the following snort
log info, a host scans for systems with the RPC services running. This scan is followed by an RPC info
query. Eighteen minutes later another
host scans for RPC services and again the scan is followed by an RPC info
query. Another host exploits the RPC
service and compromises a system the next day (notice how a scan was not done
prior to the exploit, indicating that this is probably a returning attacker
from one of the previous scans the day before).
The attack that this individual uses is quite common and was used
several times against the same system as indicated in the snort logs.
Scan from the first host:
Nov 6 16:44:14 ids snort[237]: spp_portscan: PORTSCAN DETECTED from 61.129.65.42 (STEALTH)
Nov 6 16:44:14 ids snort[237]: SCAN-SYN
FIN: 61.129.65.42:111 -> 172.16.1.102:111
Nov 6 16:44:14 ids snort[237]: SCAN-SYN
FIN: 61.129.65.42:111 -> 172.16.1.103:111
Nov 6 16:44:14 ids snort[237]: SCAN-SYN
FIN: 61.129.65.42:111 -> 172.16.1.104:111
Nov 6 16:44:14 ids snort[237]: SCAN-SYN
FIN: 61.129.65.42:111 -> 172.16.1.105:111
Nov 6 16:44:14 ids snort[237]: SCAN-SYN
FIN: 61.129.65.42:111 -> 172.16.1.107:111
Nov 6 16:44:14 ids snort[237]: SCAN-SYN
FIN: 61.129.65.42:111 -> 172.16.1.108:111
Nov 6 16:44:14 ids snort[237]: SCAN-SYN
FIN: 61.129.65.42:111 -> 172.16.1.109:111
Nov 6 16:44:19 ids snort[237]: RPC Info
Query: 61.129.65.42:777 -> 172.16.1.107:111
Nov 6 16:44:36 ids snort[237]: spp_portscan: portscan status
from 61.129.65.42: 8 connections across 7 hosts: TCP(8), UDP(0) STEALTH
Nov 6 16:44:52 ids snort[237]: spp_portscan: End of portscan
from 61.129.65.42: TOTAL time(4s) hosts(7) TCP(8) UDP(0) STEALTH
Scan from the second host:
Nov 6 17:02:50 ids snort[237]: spp_portscan: PORTSCAN DETECTED from 62.98.45.141 (STEALTH)
Nov 6 17:02:50 ids snort[237]: SCAN-SYN FIN:
62.98.45.141:111 -> 172.16.1.101:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.102:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.103:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.104:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.105:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.106:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.107:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.108:111
Nov 6 17:02:50 ids snort[237]: SCAN-SYN
FIN: 62.98.45.141:111 -> 172.16.1.109:111
Nov 6 17:02:55 ids snort[237]: RPC Info
Query: 62.98.45.141:816 -> 172.16.1.101:111
Nov 6 17:02:58 ids snort[237]: RPC Info
Query: 62.98.45.141:826 -> 172.16.1.107:111
The attack begins here:
Nov 7 23:11:05 ids snort[1260]: RPC Info
Query: 216.216.74.2:962 -> 172.16.1.101:111
Nov 7 23:11:06 ids snort[1260]: RPC Info
Query: 216.216.74.2:963 -> 172.16.1.107:111
Nov 7 23:11:31 ids snort[1260]: spp_portscan: portscan status
from 216.216.74.2: 2 connections across 1 hosts: TCP(2), UDP(0)
Nov 7 23:11:31 ids snort[1260]: IDS08 -
TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1209
Nov 7 23:11:34 ids snort[1260]: IDS08 -
TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1210
Nov 7 23:11:47 ids snort[1260]: spp_portscan: portscan status
from 216.216.74.2: 2 connections across 2 hosts: TCP(2), UDP(0)
Nov 7 23:11:51 ids snort[1260]: IDS15 -
RPC - portmap-request-status: 216.216.74.2:709 ->
172.16.1.107:111
Nov 7 23:11:51 ids snort[1260]: IDS362 -
MISC - Shellcode X86 NOPS-UDP: 216.216.74.2:710 ->
172.16.1.107:871
Nov 7 23:12:03 ids snort[1260]: spp_portscan: portscan status
from 216.216.74.2: 2 connections across 1 hosts: TCP(0), UDP(2)
Nov 7 23:12:23 ids snort[1260]: spp_portscan: portscan status
from 216.216.74.2: 1 connections across 1 hosts: TCP(1), UDP(0)
A similar attack that took
place prior shows how common this exploit is:
Nov 4 22:29:45 ids snort[5240]: RPC Info Query:
24.69.66.75:738 -> 172.16.1.107:111
Nov 4 22:30:41 ids snort[5240]: IDS15 -
RPC - portmap-request-status: 24.69.66.75:851
-172.16.1.107:111
Nov 4 22:30:41 ids snort[5240]: IDS362 -
MISC - Shellcode X86 NOPS-UDP: 24.69.66.75:852 ->
172.16.1.107:949
- What does this activity tell us about the blackhat
community?
With the information in the
previous log we can identify a few characteristics of the blackhat
community. Attackers are continually
looking for the same vulnerabilities to exploit and typically take the same
approach in identifying these vulnerabilities.
Also attackers are using similar exploits. This idea accompanied with their similar
approach would indicate that they share an abundance of information and exploit
code.
- What if anything happened in the firewall and IDS logs that gave us
a clue of what was coming? Could any of the attacks been predicted ahead
of time. If so, how?
The firewall and IDS logs
continually indicated that attackers were searching for systems running
services that are easily exploitable.
Scans for FTP and RPC services along with multiple queries to the RPC
service would indicate that these attackers are searching for vulnerable
systems. After a quick search at your
favorite security site, we would be able to make an educated guess as to what
kinds of attacks were about to come.
- What data did you find more valuable, the Snort alerts or the
firewall logs of unique scans? Why?
I made use mostly of the
Snort logs for the simple fact that I could see the destination of these scans
and attacks. It was also helpful to know
what kinds of connection attempts were being made to the internal systems.
- What lesson did you learn from this?
I’ve found substantial
information that reinforces my theories about script kiddies. First:
They don’t care who you are or what kind of business you run; they will
take advantage of your system just because they can. Second:
The community is large and shares a wealth of information (the alternative
to being truly skilled).
- How long did this challenge take you?
I spent about one day analyzing the
logs and about an hour completing the write up.
Bonus Question:
Both the Snort alerts and the inbound firewall logs missed a successful attack.
The only reason the Honeynet Project detected this
successful attack was because the compromised system attempted an outbound
connection (by definition this means a system was compromised). The Honeynet Project did a write-up on this incident, can you identify
the attack and why the Honeynet failed to alert to
the attack (though the attack was captured). Hint: the attack is written up and
posted somewhere on our site.