SANS GIAC logo
Christopher J. French
GCIA Certification Practical
23 September 2000

 Assignment #1 - Network Detects

Detect 1
Detect 2
Detect 3
Detect 4

 Assignment #2 - Evaluate an Attack

Overview
The Tests
Snapshots

 Assignment #3 - Analyze This

Suspected Compromises
Dangerous Traffic
Recommendations
Bid Ground Rules
The Bid

 Assignment #4 - Analysis Process

The Process

 Annex A - Field Descriptions

CISCO Secure IDS
TCPDUMP
Argus
Shadow
SNORT Lightweight IDS

 Assignment #1 - Network Detects - Detect # 1

CISCO Secure IDS logs (field descriptions available in annex a)

4,1587686,2000/06/09,23:33:38,2000/06/09,19:33:38,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.3,1539,53,0.0.0.0,1359273165
4,1587687,2000/06/09,23:33:38,2000/06/09,19:33:38,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.18,1554,53,0.0.0.0,1361126409
4,1587688,2000/06/09,23:33:38,2000/06/09,19:33:38,10008,5,5000,IN,OUT,3,3000,53,TCP/IP,10.0.223.18,195.117.123.171,53,1554,0.0.0.0,1564707036
4,1587689,2000/06/09,23:33:38,2000/06/09,19:33:38,10008,5,5000,OUT,IN,3,3000,200053,TCP/IP,195.117.123.171,10.0.223.18,1554,53,0.0.0.0,1361126410
4,1587691,2000/06/09,23:33:41,2000/06/09,19:33:41,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.2,1538,53,0.0.0.0,1357575122
4,1587692,2000/06/09,23:33:43,2000/06/09,19:33:43,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.19,1555,53,0.0.0.0,1350335745
4,1587693,2000/06/09,23:33:43,2000/06/09,19:33:43,10008,5,5000,IN,OUT,3,3000,53,TCP/IP,10.0.223.19,195.117.123.171,53,1555,0.0.0.0,1040335095
4,1587694,2000/06/09,23:33:43,2000/06/09,19:33:43,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.22,1558,53,0.0.0.0,1362574928
4,1587695,2000/06/09,23:33:43,2000/06/09,19:33:43,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.21,1557,53,0.0.0.0,1352580843
4,1587696,2000/06/09,23:33:43,2000/06/09,19:33:43,10008,5,5000,OUT,IN,2,3030,0,TCP/IP,195.117.123.171,10.0.223.21,1557,53,0.0.0.0,
4,1587698,2000/06/09,23:33:47,2000/06/09,19:33:47,10008,5,5000,IN,OUT,3,3000,53,TCP/IP,10.0.223.19,195.117.123.171,53,1555,0.0.0.0,1040335095
4,1587699,2000/06/09,23:33:47,2000/06/09,19:33:47,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.2,1538,53,0.0.0.0,1357575122
4,1587700,2000/06/09,23:33:47,2000/06/09,19:33:47,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.3,1539,53,0.0.0.0,1359273165
4,1587701,2000/06/09,23:33:49,2000/06/09,19:33:49,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.21,1557,53,0.0.0.0,1352580843
4,1587703,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,1,4000,53,TCP/IP,195.117.123.171,10.0.223.18,1681,53,0.0.0.0,
4,1587704,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,1,4000,53,TCP/IP,195.117.123.171,10.0.223.18,1681,53,0.0.0.0,
4,1587708,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,200053,TCP/IP,195.117.123.171,10.0.223.19,1555,53,0.0.0.0,1350335746
4,1587709,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.64,1600,53,0.0.0.0,1377907698
4,1587710,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.65,1601,53,0.0.0.0,1372959718
4,1587711,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.66,1602,53,0.0.0.0,1382366731
4,1587712,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.67,1603,53,0.0.0.0,1366149770
4,1587713,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.68,1604,53,0.0.0.0,1371122494
4,1587714,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.69,1605,53,0.0.0.0,1370177279
4,1587715,2000/06/09,23:33:54,2000/06/09,19:33:54,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.70,1606,53,0.0.0.0,1382048109

Scan continues 10.0.223.71 thru 10.0.223.249

4,1587838,2000/06/09,23:33:56,2000/06/09,19:33:56,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.250,1786,53,0.0.0.0,1373209495
4,1587839,2000/06/09,23:33:56,2000/06/09,19:33:56,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.251,1787,53,0.0.0.0,1377949976
4,1587840,2000/06/09,23:33:56,2000/06/09,19:33:56,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.252,1788,53,0.0.0.0,1370963766
4,1587841,2000/06/09,23:33:56,2000/06/09,19:33:56,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.253,1789,53,0.0.0.0,1375438649
4,1587842,2000/06/09,23:33:56,2000/06/09,19:33:56,10008,5,5000,OUT,IN,3,3000,53,TCP/IP,195.117.123.171,10.0.223.254,1790,53,0.0.0.0,1368152830

ARGUS Logs (field descriptions available in annex a)

Fri 06/09 19:33:39 tcp 195.117.123.171.1558 <| 10.0.223.22.53 1 1 0 0 RST
Fri 06/09 19:33:39 M tcp 195.117.123.171.1557 <| 10.0.223.21.53 1 1 0 0 RST
Fri 06/09 19:33:50 udp 195.117.123.171.1681 <-> 10.0.223.18.53 1 1 35 35 ACC
Fri 06/09 19:33:34 tcp 195.117.123.171.1554 o> 10.0.223.18.53 4 3 0 0 TIM
Fri 06/09 19:33:43 s tcp 195.117.123.171.1538 o> 10.0.223.2.53 2 0 0 0 TIM
Fri 06/09 19:33:43 s tcp 195.117.123.171.1539 o> 10.0.223.3.53 2 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1600 o> 10.0.223.64.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1601 o> 10.0.223.65.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1602 o> 10.0.223.66.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1603 o> 10.0.223.67.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1604 o> 10.0.223.68.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1605 o> 10.0.223.69.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1606 o> 10.0.223.70.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1607 o> 10.0.223.71.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1609 o> 10.0.223.73.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1610 o> 10.0.223.74.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1608 o> 10.0.223.72.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1611 o> 10.0.223.75.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1612 o> 10.0.223.76.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1613 o> 10.0.223.77.53 1 0 0 0 TIM
Fri 06/09 19:33:51 tcp 195.117.123.171.1614 o> 10.0.223.78.53 1 0 0 0 TIM
Fri 06/09 19:33:52 tcp 195.117.123.171.1786 o> 10.0.223.250.53 1 0 0 0 TIM
Fri 06/09 19:33:52 tcp 195.117.123.171.1787 o> 10.0.223.251.53 1 0 0 0 TIM
Fri 06/09 19:33:52 tcp 195.117.123.171.1788 o> 10.0.223.252.53 1 0 0 0 TIM
Fri 06/09 19:33:52 tcp 195.117.123.171.1789 o> 10.0.223.253.53 1 0 0 0 TIM
Fri 06/09 19:33:52 tcp 195.117.123.171.1790 o> 10.0.223.254.53 1 0 0 0 TIM
Fri 06/09 19:33:50 udp 195.117.123.171.1681 <-> 10.0.223.18.53 1 1 38 38 TIM

1. Source of trace:
These traces were picked up between our border router and internal firewalls on our own network.
  
2. Detect was generated by:
The logs from which this detect were originally noted from CISCO Secure IDS (formerly NetRanger). The actual discovery for this practical assignment however came by querying a Microsoft Access database for numerous TCP hits on port 53 for a specific date. Once data had been narrowed down to an attack of interest, the raw logs from the CISCO Secure IDS were pulled and examined. Other sources of data that may have logged this detect were then sought. ARGUS logs were available for this time period and upon inspection picked up this activity.
  
3. Probability the source address was spoofed:
The attacker was doing reconnaissance. It is probable that the source address was not spoofed.  Reasoning for this is that it is difficult to spoof an address and receive a response. As this is an apparent scan of a whole Class C address range, the attacker is hoping for replies (different source ports are used for each address scanned). A nslookup was performed on the 195.117.123.171 and the query returned the domain name "gateway.orfe.pl" from UnivNet, Warsaw, Poland. It is possible the gateway is doing Network Address Translation (NAT), however, no other traffic has been noted coming from this address during the timeframe April to August. Therefore this scan is most probably from either a compromised host behind the gateway, or from an organisation that is/was not aware a user was performing this type of activity. The intent is apparently for reconnaissance and it is unlikely that the source address was spoofed. Unfortunately the TTL is not available in the logs and more in-depth analysis using this piece of data is not possible.
  
4. Description of attack:
This is a scan for services offered through TCP port 53. TCP connections to the well-known port 53 are usually destined for Domain Name Service servers and most often for the purposes of transferring zones. A response from a server means it is reachable and is a potential target for future attacks. These may include further reconnaissance to map internal networks, poisoning DNS entries to reflect improper information, denial of service attacks on internal and external users trying to reach this domain, and attempts to compromise the host via DNS related vulnerabilities.

CVE-1999-0024 - Cache Poisoning
CVE-1999-0274 - Denial of Service
23 other CVE's related to DNS scans are available.
 
     
5. Attack mechanism:
The attacker, 195.117.123.171, attempted to find DNS servers within a specified address range, besides 10.0.223.18 and 10.0.223.19 which had already been determined as DNS servers. This is indicated by query attempts made prior to the scan. At the same time, evaluation of the DMZ and DNS servers for potential vulnerabilities associated with being able to make TCP connections was accomplished.
Due to time variance in the systems providing logs, ARGUS logs are 3 seconds ahead of CISCO Secure IDS.

The TCP connection attempts to sequential destination addresses most probably started at 10.0.223.1 and continued to 10.0.223.254, however the border router is configured to drop connections to non-existent hosts and connection attempts would not make it to the IDS. The attacker initiated specific reconnaissance against network infrastructure targets in the 0-22 host address range prior to his scan of the whole Class C network. A UDP query was also directed to the DNS server at 10.0.223.18 and a response was sent back during this time. Unfortunately the actual request is not known. This is 16 seconds after the attacker initiated activity and occurs at the same time as the larger scan. This indicates that the attacker is scanning in the background and interactively reacting to the output.

Besides the DNS servers, none of the hosts targeted during the 19:33:50 Ė 19:33:52 time period responded as ARGUS indicates they all timed out after 1 packet. However, it is interesting to see that 4 TCP packets were sent to host 18 and 2 each to hosts 2 and 3 (a standard location for DNS servers but are actually two of our firewalls). Another item of note is that the source port is incrementing in a normal range. This indicates that the scan was not performed with a crafting script.

6. Correlation:
Correlations were arrived at initially as a result of having more than one source of information from our own network. Upon searching the SANS site however, more were found. Apparently this address has been noted by numerous sites scanning for DNS. The following URL's reference this IP address. Both of these detects are post when our network was hit.

www.sans.org/y2k/062900.htm
www.sans.org/y2k/071400.htm

Other correlations are:
packetstorm.securify.com/trojans/dnsscan
 
7. Evidence of active targeting:
This detect indicates active targeting of the 10.0.223.0/24 network. CISCO Secure IDS did not note any other connection attempts from the attacker. Hence this was active targeting of the network for a service at port 53, most probably DNS.
     
8. Severity:

Target Criticality = 5

The targets were  DNS servers. The network information contained in the records and the importance  of DNS to our users makes the targets of this attack very  critical

Attack Lethality = 1

This detect is a  probe. The only traffic exchanged appears to be a query. No payload could be  determined from logs available.

System Countermeasures =  3

Target systems are  well maintained and patched.

Network Countermeasures =  5

Intrusion Detection  Systems, well maintained firewall, router ACLís, and a current Security  Policy.

(5 + 1) - (3 + 5) = - 2
Using the formula Severity = (Target  Criticality + Attack Lethality) - (System Countermeasures + Network  Countermeasures) the following severity has been  determined.



9. Defensive recommendation:
It is difficult to stop these types of scans. Calling the Internic registered owner of the network 195.117.123.171 to see if they are aware of the objectionable traffic generating from their address range is the most profitable course of action. Perhaps it is a compromised host and more information about the originator of the traffic may be gained, or more knowledge of the tool used may be found. It is likely that this is an organization that is intentionally scanning the Internet to record DNS server locations for integration into a list for sale or future targets of interest. It is possible that this is a government or military site.
Doing an internal vulnerability scan with current signatures of the DNS server, and performing routine maintenance/patching/updating will lower chances of a successful attack against the server.

Making sure that TCP connections to the DNS server are limited to trusted hosts.
 
10. Multiple choice test question
 
DNS is used for what? 
     
A. To find out what port a web server is operating on.
B. To authenticate a designated name splice.
C. To map between IP address and domain name.
D. To filter packets in your DMZ. 
     
C is the correct answer. 

 Detect # 2

CISCO Secure IDS logs (field descriptions available in annex a)

4,2204799,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.2,111,111,0.0.0.0,665720017
4,2204800,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,5,3041,0,TCP/IP,63.197.4.191,10.0.223.2,111,111,0.0.0.0,
4,2204801,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.3,111,111,0.0.0.0,665720017 
4,2204802,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.18,111,111,0.0.0.0,665720017
4,2204803,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,IN,OUT,3,3000,300111,TCP/IP,10.0.223.18,63.197.4.191,111,111,0.0.0.0,0
4,2204804,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.19,111,111,0.0.0.0,665720017
4,2204805,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,IN,OUT,3,3000,300111,TCP/IP,10.0.223.19,63.197.4.191,111,111,0.0.0.0,0
4,2204806,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.21,111,111,0.0.0.0,665720017
4,2204807,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,IN,OUT,3,3000,300111,TCP/IP,10.0.223.21,63.197.4.191,111,111,0.0.0.0,1408360665
4,2204808,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.22,111,111,0.0.0.0,665720017
4,2204809,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,OUT,IN,5,3036,0,TCP/IP,63.197.4.191,10.0.223.22,111,111,0.0.0.0,
4,2204810,2000/06/01,10:57:01,2000/06/01,06:57:01,10008,5,5000,IN,OUT,3,3000,300111,TCP/IP,10.0.223.22,63.197.4.191,111,111,0.0.0.0,0
4,2204811,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.64,111,111,0.0.0.0,360849624
4,2204812,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.65,111,111,0.0.0.0,360849624
4,2204813,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.66,111,111,0.0.0.0,360849624
4,2204814,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.67,111,111,0.0.0.0,360849624
4,2204815,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.68,111,111,0.0.0.0,360849624
4,2204816,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.69,111,111,0.0.0.0,360849624
4,2204817,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.70,111,111,0.0.0.0,360849624
4,2204818,2000/06/01,10:57:02,2000/06/01,06:57:02,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.71,111,111,0.0.0.0,360849624
4,2204834,2000/06/01,10:57:03,2000/06/01,06:57:03,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.87,111,111,0.0.0.0,360849624
4,2204835,2000/06/01,10:57:03,2000/06/01,06:57:03,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.88,111,111,0.0.0.0,360849624
4,2204836,2000/06/01,10:57:03,2000/06/01,06:57:03,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.89,111,111,0.0.0.0,360849624
4,2204837,2000/06/01,10:57:03,2000/06/01,06:57:03,10008,5,5000,OUT,IN,3,3000,111,TCP/IP,63.197.4.191,10.0.223.90,111,111,0.0.0.0,360849624

Shadow Logs (field descriptions available in annex a)

Shadow Hourly Report
Site: goodguys1 - Date: Jun01 - EDT: 06:00. 
63.197.4.191 > 10.0.223.2

06:57:50.734869 63.197.4.191.111 > host1.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:50.760410 63.197.4.191.111 > host2.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:51.056561 63.197.4.191.111 > host3.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:51.078469 63.197.4.191.111 > host4.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:51.118624 63.197.4.191.111 > host5.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:51.129592 63.197.4.191.111 > host6.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:51.974248 63.197.4.191.111 > broadcast.111: SF 360849624:360849624(0) win 1028
06:57:51.996143 63.197.4.191.111 > host1gw.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.014390 63.197.4.191.111 > host7.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.036830 63.197.4.191.111 > host8.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.047783 63.197.4.191.111 > testbed1.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.073324 63.197.4.191.111 > testbed2.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.084279 63.197.4.191.111 > testbed3.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.117112 63.197.4.191.111 > testbed4.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.139004 63.197.4.191.111 > testbed5.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.157252 63.197.4.191.111 > printer1.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.175499 63.197.4.191.111 > 10.0.223.74.111: SF 360849624:360849624(0) win 1028
06:57:52.197392 63.197.4.191.111 > host9.goodguys.com.111: SF 360849624:360849624(0) win 1028
06:57:52.212007 63.197.4.191.111 > 10.0.223.76.111: SF 360849624:360849624(0) win
. . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . .
06:57:55.436755 63.197.4.191.111 > 10.0.223.237.111: SF 520341880:520341880(0) win 1028
06:57:55.447709 63.197.4.191.111 > 10.0.223.238.111: SF 520341880:520341880(0) win 1028
06:57:55.476280 63.197.4.191.111 > BroadCast.111: SF 520341880:520341880(0) win 1028
06:57:55.495155 63.197.4.191.111 > SubNet.111: SF 520341880:520341880(0) win 1028
06:57:55.517050 63.197.4.191.111 > ts04-p01.ppp1.goodguys.com.111: SF 520341880:520341880(0) win 1028
06:57:55.535296 63.197.4.191.111 > ts04-p02.ppp2.goodguys.com.111: SF 520341880:520341880(0) win 1028
06:57:55.557190 63.197.4.191.111 > ts04-p03.ppp3.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.568144 63.197.4.191.111 > ts04-p04.ppp4.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.598030 63.197.4.191.111 > ts04-p05.ppp5.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.608833 63.197.4.191.111 > ts04-p06.ppp6.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.641662 63.197.4.191.111 > ts04-p07.ppp7.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.656264 63.197.4.191.111 > ts04-p08.ppp8.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.674528 63.197.4.191.111 > ts04-p09.ppp9.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.692776 63.197.4.191.111 > ts04-p10.ppp10.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.714669 63.197.4.191.111 > ts04-p11.ppp11.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.725622 63.197.4.191.111 > ts04-p12.ppp12.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.754810 63.197.4.191.111 > ts04-p13.ppp13.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.765764 63.197.4.191.111 > ts04-p14.ppp14.goodguys.com.111: SF 1289839450:1289839450(0) win 1028
06:57:55.805903 63.197.4.191.111 > 10.0.223.255.111: SF 1289839450:1289839450(0) win 1028

num dests  source ip         source name

198        63.197.4.191
104        10.0.223.18    host18.goodguys.com
51         10.0.223.19    host19.goodguys.com
17         10.0.223.22    host20.goodguys.com
23         10.0.223.109   host109.goodguys.com
31         10.0.223.111   host111.goodguys.com
15         10.0.223.123   host123.goodguys.com
Site: goodguys1 - Date: Jun01 - EDT: 06:00.

1. Source of trace:
These traces were logged on our network between the border router and internal firewalls.
  
2. Detect was generated by:
A CISCO Secure IDS sensor picked up this traffic, as well as a Shadow sensor.  As with detect number 1, this was archived data, retrieved through a query of an Access Database where lower fidelity trace records are stored.  Raw Shadow logs however had been purged, due to the size and time variance since the original detect.  Additional sources of data were sought in addition to the two above.  It was noted that ARGUS logs did not contain any traces of this scan.  This is due to the flags used by the scanner.
  
3. Probability the source address was spoofed:
This Remote Procedure Call scan is comprised of crafted packets.  The source is looking for replies and resolves to ads1-63-197-4-191.ds1.snfc21.pacbell.net.  This appears to be a user dial-up account.  It is unlikely that it was spoofed and is more likely to be a stolen account or user violating AUP's.
  
4. Description of attack:
This attack is scanning the portmapper service on a range of hosts within a Class C address space.  The packets contain duplicate TCP sequence numbers and all have the Syn/Fin flags set to try and evade Firewalls and IDS'.

This is known as a RPC scan which usually target unix based systems on tcp port 111.  A service called the portmapper listens on this port. Portmapper directs the party requesting an offered service to the arbitrary port assigned by the system. The requestor is then connected to the desired service. The following list is a sample of services available through RPC:
 

- etherstatd

-  rstatd

- mountd

- rusersd

- nfs

- sprayd

- nispasswd

- walld

- nisd

- ypbind

- rexd

- yppasswdd

- rpcnfs

- ypserv

- rquotad



There are network reconnaissance techniques which use the portmapper to gather information for future attacks.  This can usually give enough information to compromise the host in question and gain root access.  An example would be a buffer overflow targeted at a service such as rstatd running on the host.  

cve-1999-0008 and 27 other cve's came up on a search of "rpc + scan"

5. Attack mechanism:
As stated previously, the source packets of this detect are crafted.  A tool similar to NMAP may have been used, however NMAP is presently incapable of crafting a win size of 1028, which rules out this specific tool.  It is probable that the attacker is targeting UNIX based systems, however, other Operating systems such as Microsoft NT would respond as well if listening on this port.

Analysis of the Shadow report reveals that the same duplicate sequence numbers are used in the source packets.  The Syn/Fin flags are set too, trying to evade Intrusion Detection Systems.  This technique was successful in evading ARGUS as none of this activity was noted in those logs.  The default IP & HOST filter was used on Shadow.  Note the highlighted fields below.  

06:57:50.734869 63.197.4.191.111 > host1.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:50.760410 63.197.4.191.111 > host2.goodguys.com.111: SF 665720017:665720017(0) win 1028
(fingerprint of Synscan)

Analysis of the CISCO Secure IDS logs confirm the activity, which correlates the ports, time, and IP addresses involved.  These logs also indicate TCP responses from specific hosts.  The highlighted CISCO Secure IDS logs at the beginning of this assignment indicate TCP connections from our hosts to the attacker. These are not as critical as first anticipated.  The hosts that replied have TCP Wrappers installed.  When connections are noted by the kernel to unprivileged ports, by unauthorized hosts, TCP resets are sent.  This still provides some trivial information, however in a mass scan such as this, the attacker is more likely looking for an easy compromise related to RPC vulnerabilities and will not even look at responses such as resets.

6. Correlation:
As discussed above in section 5, this probe was correlated with two independent logs. Generous amounts of information are available on the internet that address the use of remote procedure calls for reconnaissance or exploit.

www.cisco.com/univercd/cc/td/doc/pcat/nerg.htm
www.nswc.navy.mil/ISSEC/CID/
www.argus-systems.com/
Cert Advisory Sept 15th 2000
www.sans.org/newlook/resource/IDFAQ/trouble_RPCs.htm
www.cert.org/advisories/CA-99-16-sadmind.html
www.cert.org/advisories/CA-99-12-amd.html
www.cert.org/advisories/CA-99-08-cmsd.html
www.cert.org/advisories/CA-99-05-statd-automaountd.html
NMAP

Another detect was submitted by Del Armstrong (San Jose, 2000) that appears to have been generated by the same tool.  He arrived at pretty much the same conclusion, but unfortunately, did not know which tool was used either.

www.sans.org/y2k/practical/Del_Armstrong.htm

7. Evidence of active targeting:
This detect was actively targeted at our network. Reponses were solicited. This was a probe.
     
8. Severity:

Target Criticality =  4

The address range  scanned include computers used in research and development which we don't want  unauthorized people having access to.

Attack Lethality = 3

This detect is a  probe. No payload could be determined from logs available, however, targeting  systems for RPC vulnerabilities indicates that an exploit to compromise the  system will be carried out should the responding system be found as  vulnerable.

System Countermeasures =  4

Target systems are  well maintained and patched, with TCP Wrappers installed on servers that run  RPC.

Network Countermeasures =  5

Intrusion Detection  Systems, well maintained firewall, router ACLís, and a current Security  Policy.

(4 + 3) - (4 + 5) = -2
Using the formula Severity = (Target  Criticality + Attack Lethality) - (System Countermeasures + Network  Countermeasures) the following severity has been  determined.



9. Defensive recommendation:
It is difficult to stop these types of scans. Calling the Internic registered owner of the network to which host 63.197.4.191 belongs to see if they are aware of the objectionable traffic generating from their address range is the most profitable course of action. Perhaps it is a compromised host and more information about the originator of the traffic may be gained, or more knowledge of the tool used may be found. It is likely that this is a stolen or compromised account as the IP resolution indicates this is a dial-up account.
Doing regular internal vulnerability audits with current signatures, and performing routine maintenance/patching/updating will lower chances of a successful probe.

10. Multiple choice test question:
What fingerprint for this tool can best be derived from these log entries?

06:57:50.734869 63.197.4.191.111 > host1.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:50.760410 63.197.4.191.111 > host2.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:51.056561 63.197.4.191.111 > host3.goodguys.com.111: SF 665720017:665720017(0) win 1028
06:57:51.078469 63.197.4.191.111 > host4.goodguys.com.111: SF 665720017:665720017(0) win 1028


A. Syn/Fin flag set
B. Window size is a constant 1028
C. Source and destination ports are equal
D. All of the above.
     
D is the correct answer.

 Detect # 3

CISCO Secure IDS logs (field descriptions available in annex a)

4,1566108,2000/09/13,16:42:00,2000/09/13,12:42:00,10008,5,5000,IN,OUT,3,3213,0,TCP/IP,172.16.0.119,205.158.26.242,50321,80,0.0.0.0,
test-cgi terminated with *,
6F7A696C6C612F342E3631205B656E5D20285831313B20493B2053756E4F5320352E362073756E3475290D0A486F73743A207777772E7730307
730302E6F72670D0A4163636570743A20696D6167652F6769662C20696D6167652F782D786269746D61702C20696D6167652F6A7065672C20696
D6167652F706A7065672C20696D6167652F706E672C202A2F2A0D0A4163636570742D456E636F64696E673A20677A69700D0A4163636570742D
4C616E67756167653A20656E0D0A4163636570742D436861727365743A2069736F2D383835392D312C2A2C7574662D380D0A0D0A474554202F6
6696C65732F74726F6A616E732F6367692F746573742D636769ZZ6628226C697374736572763A2A3A3536373A32303A4C6973747365727620736
5727665723A2F6465762F6E756C6C3A2F62696E2F73685C6E22293B0A20202020207072696E7466282267756573743A2A3A383939393A3131303
A47756573743A2F686F6D652F67756573743A2F7573722F6C6F63616C2F62696E2F746373685C6E22293B0A20202020207072696E746628223C2F
5052453E22293B0A0A20202020207072696E746628223C2F424F44593E3C2F48544D4C3E5C6E22293B0A20207D20656C7365207B0A2020202020
50524E5345525645525228293B0A202020202046524545414C4C28293B0A20207D0A0A202046524545414C4C28293B0A7D0A


Hex to ASCII breakout of above event

  ozilla/4.61 [en] (X11; I; SunOS 5.6 sun4u)
Host: www.w00w00.org
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

 GET /files/trojans/cgi/test-cgif("listserv:*:567:20:Listserv server:/dev/null:/bin/sh\n");
     printf("guest:*:8999:110:Guest:/home/guest:/usr/local/bin/tcsh\n");
     printf("</PRE>");

     printf("</BODY></HTML>\n");
  } else {
     PRNSERVERR();
     FREEALL();
  } <![endif]>

  FREEALL();
}

 
More CISCO Secure IDS Logs

4,1565659,2000/09/13,16:37:03,2000/09/13,12:37:03,10008,5,5000,IN,OUT,1,4000,53,TCP/IP,172.16.0.18,205.158.26.242,53,53,0.0.0.0,
4,1565660,2000/09/13,16:37:04,2000/09/13,12:37:04,10008,5,5000,OUT,IN,1,4000,53,TCP/IP,205.158.26.242,172.16.0.18,53,53,0.0.0.0,
4,1565661,2000/09/13,16:37:04,2000/09/13,12:37:04,10008,5,5000,IN,OUT,1,3000,80,TCP/IP,172.16.0.119,205.158.26.242,50289,80,0.0.0.0,2864488374
4,1565662,2000/09/13,16:37:04,2000/09/13,12:37:04,10008,5,5000,OUT,IN,1,3000,80,TCP/IP,205.158.26.242,172.16.0.119,80,50289,0.0.0.0,2849858975
4,1565663,2000/09/13,16:37:04,2000/09/13,12:37:04,10008,5,5000,IN,OUT,1,3000,80,TCP/IP,172.16.0.119,205.158.26.242,50290,80,0.0.0.0,2527289222
4,1565664,2000/09/13,16:37:04,2000/09/13,12:37:04,10008,5,5000,IN,OUT,1,3000,80,
. . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . .
4,1566402,2000/09/13,16:50:18,2000/09/13,12:50:18,10008,5,5000,OUT,IN,1,3000,80,TCP/IP,205.158.26.242,172.16.0.119,80,50349,0.0.0.0,2908769678
4,1566417,2000/09/13,16:50:37,2000/09/13,12:50:37,10008,5,5000,IN,OUT,1,3000,200080,TCP/IP,172.16.0.119,205.158.26.242,50349,80,0.0.0.0,1099854594

TCPDUMP Logs after being run through AscTCPDUMP (field descriptions available in annex a)

12:33:38.207229 172.16.0.18.domain > 205.158.26.242.domain: 46614+ A? www.w00w00.org. (32) (DF)
      4500 003c 5be1 4000 ff11 88c0 ac10 0012      E..<[.@......k..
      cd9e 1af2 0035 0035 0028 81cf b616 0100      .....5.5.(......
      0001 0000 0000 0000 0377 7777 0677 3030      .........www.w00
      7730 3003 6f72 6700 0001 0001                         w00.org.....
12:33:38.305365 205.158.26.242.domain > 172.16.0.18.domain: 46614* 2/3/3 CNAME medusa.blackops.org., A 205.158.26.242 (200)
      4500 00e4 6cb5 0000 3511 8145 cd9e 1af2      E...l...5..E....
      ac10 0012 0035 0035 00d0 954b b616 8580      .k...5.5...K....
      0001 0002 0003 0003 0377 7777 0677 3030      .........www.w00
      7730 3003 6f72 6700 0001 0001 c00c 0005      w00.org.........
      0001 0001 5180 0015 066d 6564 7573 6108      ....Q....medusa.
      626c 6163 6b6f 7073 036f 7267 00c0 2c00      blackops.org..,.
      0100 0100 0151 8000 04cd 9e1a f2c0 3300      .....Q........3.
      0200 0100 0151 8000 02c0 2cc0 3300 0200      .....Q....,.3...
      0100 0151 8000 0a07 7761 726c 6f63 6bc0      ...Q....warlock.
      33c0 3300 0200 0100 0151 8000 1703 6e73      3.3......Q....ns
      320d 696e 7472 612d 636f 6e6e 6563 7403      2.intra-connect.
      6e65 7400 c02c 0001 0001 0001 5180 0004      net..,......Q...
      cd9e 1af2 c06b 0001 0001 0001 5180 0004      .....k......Q...
      d870 0c8e c081 0001 0001 0000 242a 0004      .p..........$*..
      8cba 7863                                                            ..xc
12:33:38.339480 172.16.0.119.50289 > 205.158.26.242.www: S 2864488374:2864488374(0) win 8760 <mss 1460> (DF)
      4500 002c 911f 4000 fe06 5438 ac10 0077      E..,..@...T8.k.w
      cd9e 1af2 c471 0050 aabc 9fb6 0000 0000      .....q.P........
      6002 2238 cf45 0000 0204 05b4 0000               `."8.E........
12:33:38.433426 205.158.26.242.www > 172.16.0.119.50289: S 2849858975:2849858975(0) ack 2864488375 win 16384 <mss 512>
      4500 002c 1414 0000 3506 da44 cd9e 1af2      E..,....5..D....
      ac10 0077 0050 c471 a9dd 659f aabc 9fb7      .k.w.P.q..e.....
      6012 4000 a5a3 0000 0204 0200 0000               `.@...........
12:33:38.435716 172.16.0.119.50289 > 205.158.26.242.www: P 1:345(344) ack 1 win 9216 (DF)
      4500 0180 9121 4000 fe06 52e2 ac10 0077      E....!@...R..k.w
      cd9e 1af2 c471 0050 aabc 9fb7 a9dd 65a0      .....q.P......e.
      5018 2400 8e73 0000 4745 5420 2f20 4854      P.$..s..GET / HT
      5450 2f31 2e30 0d0a 5265 6665 7265 723a      TP/1.0..Referer:
      2068 7474 703a 2f2f 7777 772e 7769 7265       http://www.wire
      7472 6970 2e6e 6574 2f72 6670 2f70 6167      trip.net/rfp/pag
      6573 2f72 6573 6f75 7263 6573 2e61 7370      es/resources.asp
      3f69 6661 6365 3d32 0d0a 436f 6e6e 6563      ?iface=2..Connec
      7469 6f6e 3a20 4b65 6570 2d41 6c69 7665      tion: Keep-Alive
      0d0a 5573 6572 2d41 6765 6e74 3a20 4d6f      ..User-Agent: Mo
      7a69 6c6c 612f 342e 3631 205b 656e 5d20      zilla/4.61 [en]
      2858 3131 3b20 493b 2053 756e 4f53 2035      (X11; I; SunOS 5
      2e36 2073 756e 3475 290d 0a48 6f73 743a      .6 sun4u)..Host:
      2077 7777 2e77 3030 7730 302e 6f72 670d       www.w00w00.org.
      0a41 6363 6570 743a 2069 6d61 6765 2f67      .Accept: image/g
      6966 2c20 696d 6167 652f 782d 7862 6974      if, image/x-xbit
      6d61 702c 2069 6d61 6765 2f6a 7065 672c      map, image/jpeg,
      2069 6d61 6765 2f70 6a70 6567 2c20 696d       image/pjpeg, im
      6167 652f 706e 672c 202a 2f2a 0d0a 4163      age/png, */*..Ac
      6365 7074 2d45 6e63 6f64 696e 673a 2067      cept-Encoding: g
      7a69 700d 0a41 6363 6570 742d 4c61 6e67      zip..Accept-Lang
      7561 6765 3a20 656e 0d0a 4163 6365 7074      uage: en..Accept
      2d43 6861 7273 6574 3a20 6973 6f2d 3838      -Charset: iso-88
      3539 2d31 2c2a 2c75 7466 2d38 0d0a 0d0a      59-1,*,utf-8....

TCPDUMP capture of original CISCO Secure IDS event

 12:38:33.578264 205.158.26.242.www > 172.16.0.119.50321: P 7169:7605(436) ack 353 win 16384
     4500 01dc 6f22 0000 3506 7d86 cd9e 1af2      E...o"..5.}.....
      ac10 0077 0050 c491 ab43 1b58 cadf 7545      .k.w.P...C.X..uE
      5018 4000 b6b7 0000 2f70 6f70 3a2f 7573      P.@...../pop:/us
      722f 6269 6e2f 6261 7368 5c6e 2229 3b0a      r/bin/bash\n");.
      2020 2020 2070 7269 6e74 6628 2270 6367           printf("pcg
      7565 7374 3a3a 3734 3534 3a31 3030 3a47      uest::7454:100:G
      7565 7374 2041 6363 6f75 6e74 3a2f 746d      uest Account:/tm
      703a 2f75 7372 2f62 696e 2f73 685c 6e22      p:/usr/bin/sh\n"
      293b 0a20 2020 2020 7072 696e 7466 2822      );.     printf("
      6d61 6a6f 7264 6f6d 6f3a 2a3a 3430 353a      majordomo:*:405:
      3230 3a4d 616a 6f72 646f 6d6f 2073 6572      20:Majordomo ser
      7665 723a 2f64 6576 2f6e 756c 6c3a 2f62      ver:/dev/null:/b
      696e 2f73 7461 7274 646f 6d6f 5c6e 2229      in/startdomo\n")
      3b0a 2020 2020 2070 7269 6e74 6628 226c      ;.     printf("l
      6973 7473 6572 763a 2a3a 3536 373a 3230      istserv:*:567:20
      3a4c 6973 7473 6572 7620 7365 7276 6572      :Listserv server
      3a2f 6465 762f 6e75 6c6c 3a2f 6269 6e2f      :/dev/null:/bin/
      7368 5c6e 2229 3b0a 2020 2020 2070 7269      sh\n");.     pri
      6e74 6628 2267 7565 7374 3a2a 3a38 3939      ntf("guest:*:899
      393a 3131 303a 4775 6573 743a 2f68 6f6d      9:110:Guest:/hom
      652f 6775 6573 743a 2f75 7372 2f6c 6f63      e/guest:/usr/loc
      616c 2f62 696e 2f74 6373 685c 6e22 293b      al/bin/tcsh\n");
      0a20 2020 2020 7072 696e 7466 2822 3c2f      .     printf("</
      5052 453e 2229 3b0a 0a20 2020 2020 7072      PRE>");..     pr
      696e 7466 2822 3c2f 424f 4459 3e3c 2f48      intf("</BODY></H
      544d 4c3e 5c6e 2229 3b0a 2020 7d20 656c      TML>\n");.  } el
      7365 207b 0a20 2020 2020 5052 4e53 4552      se {.     PRNSER
      5645 5252 2829 3b0a 2020 2020 2046 5245      VERR();.     FRE
      4541 4c4c 2829 3b0a 2020 7d0a 0a20 2046      EALL();.  }..  F
      5245 4541 4c4c 2829 3b0a 7d0a                        REEALL();.}.
 
SHADOW Logs

Site: oursite Host lookup: Date: 20000913 Pattern: host 205.158.26.242

/usr/local/logger/one_day_pat.pl -S -d 20000913 -l oursite -p 'host 205.158.26.242 '

12:33:38.207229 good.guysns.com.domain > 205.158.26.242.domain: 46614+ A? www.w00w00.org. (32) (DF)
12:33:38.305365 205.158.26.242.domain > good.guysns.com.domain: 46614* 2/3/3 CNAME medusa.blackops.org., A 205.158.26.242 (200)
12:33:38.339480 good.guys1.com.50289 > 205.158.26.242.www: S 2864488374:2864488374(0) win 8760  (DF)
12:33:38.433426 205.158.26.242.www > good.guys1.com.50289: S 2849858975:2849858975(0) ack 2864488375 win 16384
12:33:38.435716 good.guys1.com.50289 > 205.158.26.242.www: P 2864488375:2864488719(344) ack 2849858976 win 9216 (DF)
. . . . . . . . . . .
SHADOW Log of CISCO Secure IDS test-cgi event follows:

12:38:33.140715 good.guys1.com.50321 > 205.158.26.242.www: P 3403641829:3403642181(352) ack 2873294680 win 9216 (DF)
. . . . . . . . . . .
12:47:11.578680 good.guys1.com.50349 > 205.158.26.242.www: F 1099854594:1099854594(0) ack 2908776065 win 9216 (DF)
12:47:11.675396 205.158.26.242.www > good.guys1.com.50349: F 2908776065:2908776065(0) ack 1099854595 win 16384
 
1. Source of trace:
This trace was picked up on an internal CISCO Secure IDS sensor located between the firewalls and border router.
  
2. Detect was generated by:
The detect was generated by CISCO Secure IDS, TCPDUMP, and SHADOW.  Follow the links for a breakdown of the fields in the logs.

3. Probability the source address was spoofed: 
The source address was not spoofed.  The traffic originated from within our network and the user was identified and acknowledged that they had visited these sites.  The addressing prior to sanitization was legitimate for the network from which it was detected on.
 
4. Description of attack:
First indication that there may be a problem came from a CISCO Secure IDS event alarm that indicated signature 3213 had been triggered.  This triggers when an attempt is made to view directory listings with the script test-cgi.  Many versions of the NCSA httpd and apache daemons contain this script, which can be used to list directories on a server.

CVE-1999-0070

5. Attack mechanism:
This attack at first appeared to be a legitimate concern.  It looked like one of our employees was trying to exploit a test-cgi vulnerability on another server, from within work.  Very bad!  There were a sequence of events, or checks that were done to determine the validity of the alarm.

A)     The IP was checked to determine which user had carried out such a heinous action.  The IP turned out to belong to our most experienced system administrator who has extensive programming experience. 

B)      The context buffer from CISCO Secure IDS didnít contain all the traffic.  TCPDUMP and Shadow logs were available.  Upon examination of the TCPDUMP logs, the picture became much more clear.  This was not a user trying to exploit a test-cgi script, but an administrator "doing research".

C)      The TCPDUMP breakout pointed to the file was: GET /files/trojans/cgi/test-cgi.c Ö. www.w00w00.org/files/trojans/cgi.  Since the file ended with a .c, it was anticipated that this contained source C code.  This site was visited and revealed confirmed the previous notion.

D)      The file was retrieved from the server and viewed in a text editor.  It appears this is a script designed to alert administrators of web servers when an attempt is made to exploit the test-cgi vulnerability.  The system administrator got a pat on the back and more logs almost identical to the ones discussed in this detect were generated.

Understanding the source of this detect is important.  CISCO Secure IDS triggered on a context search that found ďtest-cgiĒ.  This is still a vulnerability that our company wishes to monitor for, however, in this instance it turns out to be a false positive.

6. Correlation:
More information may be found at the following URLís relating to the test-cgi vulnerability and exploit.

www.rootshell.com/archive-j457nxiqi3gq59dv/199707/test-cgi.txt.html
www.w3.org/Security/Faq/wwwsf4.html#Q35
www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids1/csidsug/sigs.htm#35211

More information on the script discussed under attack mechanism may be obtained at the following URLís.

www.w00w00.org/files/trojans/cgi/
medusa.blackops.org

7. Evidence of active targeting:
This detect indicates active targeting based upon the fact that the person involved with this detect specifically went to the proposed victim.  As it turned out to be a false positive however, it can be ascertained that this was not malicious active targeting.

8. Severity:

Target Criticality = 4

The position of a  legitimate attack against another organizations web server has been taken to  calculate Severity.

The possible  embarrassment our organization may have felt had it been real, and detected by  the victim, the trustworthiness and ethical behaviour of the employee in  question (who has access to all resources in our company) and problems arising  from addressing the issue, and the possibility of having a compromised host  inside our network, being used for further reconnaissance of other networks all  put this detects criticality at 4. (including the fact it was a web server being  targeted)

Attack  Lethality = 1

This was not a lethal attack, assuming that  the test-cgi script is the one described in CVE-1999-0070. This is more of a probe that could aid an  attacker in compromising the server if the vulnerability exists.  This is a well known vulnerability and has  had plenty of time to be addressed by vendors since 1996. For these reasons attack lethality is rated  at 1.

System  Countermeasures = 0

There were no system  countermeasures in place to disable the system administrator from carrying out  this suspected attack.

Network  Countermeasures = 5

Intrusion Detection  Systems, well maintained firewalls, router ACLís, and a current Security  Policy.

(4 + 1) -  (0 + 5) = 0

Using the  formula Severity = (Target Criticality + Attack Lethality) - (System  Countermeasures + Network Countermeasures) the following severity has been  determined.



9. Defensive recommendation:
Recommendation one is to continuous monitoring of the IDSí for inappropriate usage.  The other recommendation is to ensure employees are aware of the companies ďAcceptable Use PolicyĒ and what administrative action may be taken against employees who do break the policy.

10. Multiple choice test question:
What indication is present that indicates this is a false positive cgi-bin exploit? 

12:38:33.578264 205.158.26.242.www > 172.16.0.119.50321: P 7169:7605(436) ack 353 win 16384

4500 01dc 6f22 0000 3506 7d86 cd9e 1af2
ac10 0077 0050 c491 ab43 1b58 cadf 7545
5018 4000 b6b7 0000 2f70 6f70 3a2f 7573
722f 6269 6e2f 6261 7368 5c6e 2229 3b0a
2020 2020 2070 7269 6e74 6628 2270 6367
7565 7374 3a3a 3734 3534 3a31 3030 3a47
7565 7374 2041 6363 6f75 6e74 3a2f 746d
703a 2f75 7372 2f62 696e 2f73 685c 6e22
293b 0a20 2020 2020 7072 696e 7466 2822
6d61 6a6f 7264 6f6d 6f3a 2a3a 3430 353a
3230 3a4d 616a 6f72 646f 6d6f 2073 6572
7665 723a 2f64 6576 2f6e 756c 6c3a 2f62
696e 2f73 7461 7274 646f 6d6f 5c6e 2229
3b0a 2020 2020 2070 7269 6e74 6628 226c
6973 7473 6572 763a 2a3a 3536 373a 3230
3a4c 6973 7473 6572 7620 7365 7276 6572
3a2f 6465 762f 6e75 6c6c 3a2f 6269 6e2f
7368 5c6e 2229 3b0a 2020 2020 2070 7269
6e74 6628 2267 7565 7374 3a2a 3a38 3939
393a 3131 303a 4775 6573 743a 2f68 6f6d
652f 6775 6573 743a 2f75 7372 2f6c 6f63
616c 2f62 696e 2f74 6373 685c 6e22 293b
0a20 2020 2020 7072 696e 7466 2822 3c2f
5052 453e 2229 3b0a 0a20 2020 2020 7072
696e 7466 2822 3c2f 424f 4459 3e3c 2f48
544d 4c3e 5c6e 2229 3b0a 2020 7d20 656c
7365 207b 0a20 2020 2020 5052 4e53 4552
5645 5252 2829 3b0a 2020 2020 2046 5245
4541 4c4c 2829 3b0a 2020 7d0a 0a20 2046
5245 4541 4c4c 2829 3b0a 7d0a

E...o"..5.}.....
.k.w.P...C.X..uE
P.@...../pop:/us
r/bin/bash\n");.
     printf("pcg
uest::7454:100:G
uest Account:/tm
p:/usr/bin/sh\n"
);.     printf("
majordomo:*:405:
20:Majordomo ser
ver:/dev/null:/b
in/startdomo\n")
;.     printf("l
istserv:*:567:20
:Listserv server
:/dev/null:/bin/
sh\n");.     pri
ntf("guest:*:899
9:110:Guest:/hom
e/guest:/usr/loc
al/bin/tcsh\n");
.     printf("</
PRE>");..     pr
intf("</BODY></H
TML>\n");.  } el
se {.     PRNSER
VERR();.     FRE
EALL();.  }..  F
REEALL();.}.



A. The source is noted sending from port 80 or www.
B. The hex breakout includes reference to a Guest Account.
C.  The window size is 16384.
D. There are HTML tags within the hex breakout.

The most correct answer is D.  This is an HTML page containing a script, sent in response to a previous client GET command.

 Detect #4

7th Shadow logs (field descriptions available in annex a)
The date is 0907 (MMDD) timezone Eastern and the filter is -n -v ip and host 202.108.221.51

13:41:50.539038 202.108.221.51.80 > 172.16.183.167.34575: R 0:0(0) ack 2265907201 win 0 (ttl 109, id 7656)
13:42:22.991349 202.108.221.51.80 > 172.16.203.123.4131: R 0:0(0) ack 270729217 win 0 (ttl 109, id 15917)
22:20:14.921010 202.108.221.51.80 > 172.16.88.207.47139: R 0:0(0) ack 3089301505 win 0 (ttl 109, id 3384)
22:22:24.463967 202.108.221.51.80 > 172.16.65.142.1052: R 0:0(0) ack 68943873 win 0 (ttl 110, id 15414)

8th Shadow logs
01:50:13.119057 202.108.221.51.80 > 172.16.97.53.12305: R 0:0(0) ack 806420481 win 0 (ttl 109, id 58680)
02:21:22.573921 202.108.221.51.80 > 172.16.133.234.5391: R 0:0(0) ack 353304577 win 0 (ttl 110, id 24263)
02:21:25.789872 202.108.221.51.80 > 172.16.175.255.35609: R 0:0(0) ack 2333671425 win 0 (ttl 110, id 24568)
02:23:50.847450 202.108.221.51.80 > 172.16.144.40.16929: R 0:0(0) ack 1109458945 win 0 (ttl 110, id 38470)
02:38:27.512266 202.108.221.51.80 > 172.16.209.236.56354: R 0:0(0) ack 3693215745 win 0 (ttl 107, id 58289)
............Time Lapse............
23:55:38.156840 202.108.221.51.80 > 172.16.201.82.32261: R 0:0(0) ack 2114256897 win 0 (ttl 109, id 36476)

TCPDUMP logs (field descriptions available in annex a)
04:46:37.862678 202.108.221.51.80 > 172.16.42.191.38159: S 333056621:333056621(0) ack 2500788225 win 16616 <mss 1460> (DF) (ttl 110, id 59021)
04:46:40.799690 202.108.221.51.80 > 172.16.42.191.38159: S 333056621:333056621(0) ack 2500788225 win 16616 <mss 1460> (DF) (ttl 110, id 59480)
04:46:46.805398 202.108.221.51.80 > 172.16.42.191.38159: S 333056621:333056621(0) ack 2500788225 win 16616 <mss 1460> (DF) (ttl 110, id 60429)
04:49:32.537454 202.108.221.51.80 > 172.16.23.167.47119: R 0:0(0) ack 3087990785 win 0 (ttl 107, id 20203)
............Time Lapse............
23:55:38.156840 202.108.221.51.80 > 172.16.201.82.32261: R 0:0(0) ack 2114256897 win 0 (ttl 109, id 36476)

TCPDUMP logs run through AscTCPDUMP  
02:21:22.573921 202.108.221.51.80 > 172.16.133.234.5391: R 0:0(0) ack 353304577 win 0 (ttl 110, id 24263)
4500 0028 5ec7 0000 6e06 3cf5 ca6c dd33     E..(^...n.<..l.3
ac10 85ea 0050 150f 0000 0000 150f 0001     .....P..........
5014 0000 d44d 0000 0000 0000 0000          P....M........

02:21:25.789872 202.108.221.51.80 > 172.16.175.255.35609: R 0:0(0) ack 2333671425 win 0 (ttl 110, id 24568)
4500 0028 5ff8 0000 6e06 11af ca6c dd33     E..(_...n....l.3
ac10 afff 0050 8b19 0000 0000 8b19 0001     .....P..........
5014 0000 be23 0000 0000 0000 0000            P....#........

02:23:50.847450 202.108.221.51.80 > 172.16.144.40.16929: R 0:0(0) ack 1109458945 win 0 (ttl 110, id 38470)
4500 0028 9646 0000 6e06 fb37 ca6c dd33     E..(.F..n..7.l.3
ac10 9028 0050 4221 0000 0000 4221 0001     ...(.PB!....B!..
5014 0000 6feb 0000 0000 0000 0000                  P...o.........

02:38:27.512266 202.108.221.51.80 > 172.16.209.236.56354: R 0:0(0) ack 3693215745 win 0 (ttl 107, id 58289)
4500 0028 e3b1 0000 6b06 6f08 ca6c dd33     E..(....k.o..l.3
ac10 d1ec 0050 dc22 0000 0000 dc22 0001     .....P."....."..
5014 0000 fa23 0000 0000 0000 0000                P....#........ 

9th Shadow logs
00:03:28.524138 202.108.221.51.80 > 172.16.171.93.32028: R 0:0(0) ack 2098987009 win 0 (ttl 109, id 16161)
00:05:07.837864 202.108.221.51.80 > 172.16.135.171.7205: R 0:0(0) ack 472186881 win 0 (ttl 110, id 34779)
00:05:26.781783 202.108.221.51.80 > 172.16.96.189.515: R 0:0(0) ack 33751041 win 0 (ttl 110, id 1607)
00:06:41.044737 202.108.221.51.80 > 172.16.177.80.3611: R 0:0(0) ack 236650497 win 0 (ttl 110, id 55016)
............Time Lapse............
09:17:02.473881 172.16.96.3.53 > 202.108.221.51.1026: 5679* 0/1/0 (94) (DF) (ttl 254, id 14037)
09:17:05.461702 202.108.221.51.1026 > 172.16.96.3.53: 5679 A? ncs.dnd.ca. (28) (ttl 109, id 18843)
09:17:05.463814 172.16.96.3.53 > 202.108.221.51.1026: 5679* 0/1/0 (94) (DF) (ttl 254, id 14038)

TCPDUMP logs run through AscTCPDUMP
00:03:28.524138 202.108.221.51.80 > 172.16.171.93.32028: R 0:0(0) ack 2098987009 win 0 (ttl 109, id 16161)
4500 0028 3f21 0000 6d06 3828 ca6c dd33     E..(?!..m.8(.l.3
ac10 ab5d 0050 7d1c 0000 0000 7d1c 0001     ...].P}.....}...
5014 0000 debf 0000 0000 0000 0000                  P.............

00:05:07.837864 202.108.221.51.80 > 172.16.135.171.7205: R 0:0(0) ack 472186881 win 0 (ttl 110, id 34779)
4500 0028 87db 0000 6e06 1220 ca6c dd33     E..(....n.. .l.3
ac10 87ab 0050 1c25 0000 0000 1c25 0001     .....P.%.....%..
5014 0000 c460 0000 0000 0000 0000                    P....`........

00:05:26.781783 202.108.221.51.80 > 172.16.96.189.515: R 0:0(0) ack 33751041 win 0 (ttl 110, id 1607)
4500 0028 0647 0000 6e06 baa2 ca6c dd33     E..(.G..n....l.3
ac10 60bd 0050 0203 0000 0000 0203 0001     ..`..P..........
5014 0000 1f93 0000 0000 0000 0000                P.............

00:06:41.044737 202.108.221.51.80 > 172.16.177.80.3611: R 0:0(0) ack 236650497 win 0 (ttl 110, id 55016)
4500 0028 d6e8 0000 6e06 996d ca6c dd33      E..(....n..m.l.3
ac10 b150 0050 0e1b 0000 0000 0e1b 0001     ...P.P..........
5014 0000 b6cf 0000 0000 0000 0000                 P.............

00:07:45.822712 202.108.221.51.80 > 172.16.251.15.1802: R 0:0(0) ack 118095873 win 0 (ttl 110, id 23399)
4500 0028 5b67 0000 6e06 cb2f ca6c dd33     E..([g..n../.l.3
ac10 fb0f 0050 070a 0000 0000 070a 0001     .....P..........
5014 0000 7b32 0000 0000 0000 0000             P...{2........

00:07:50.470800 202.108.221.51.80 > 172.16.253.209.24357: R 0:0(0) ack 1596260353 win 0 (ttl 109, id 30782)
4500 0028 783e 0000 6d06 ac96 ca6c dd33     E..(x>..m....l.3
ac10 fdd1 0050 5f25 0000 0000 5f25 0001     .....P_%...._%..
5014 0000 c839 0000 0000 0000 0000             P....9........

10th Shadow logs
13:29:22.219733 202.108.221.51.80 > 172.16.209.158.19478: R 0:0(0) ack 1276510209 win 0 (ttl 109, id 26296)
13:29:52.332620 202.108.221.51.80 > 172.16.181.112.38158: R 0:0(0) ack 2500722689 win 0 (ttl 110, id 14274)
13:30:05.268571 202.108.221.51.80 > 172.16.9.147.6423: R 0:0(0) ack 420937729 win 0 (ttl 110, id 37444)
13:30:20.514107 202.108.221.51.80 > 172.16.77.217.10767: R 0:0(0) ack 705626113 win 0 (ttl 110, id 64791)


11th Shadow logs
11:14:14.651347 202.108.221.51.80 > 172.16.213.229.17683: R 0:0(0) ack 1158873089 win 0 (ttl 109, id 48603)
11:14:31.523764 202.108.221.51.80 > 172.16.22.219.1536: R 0:0(0) ack 100663297 win 0 (ttl 109, id 13361)
11:15:13.640620 202.108.221.51.80 > 172.16.196.164.44036: R 0:0(0) ack
............Time Lapse............
23:58:42.294465 202.108.221.51.80 > 172.16.154.14.32793: R 0:0(0) ack 2149122049 win 0 (ttl 110, id 26363)


12th Shadow logs
00:00:14.985363 202.108.221.51.80 > 172.16.166.2.50712: R 0:0(0) ack 3323461633 win 0 (ttl 109, id 60002)
00:01:28.312280 202.108.221.51.80 > 172.16.20.247.54297: R 0:0(0) ack 3558408193 win 0 (ttl 109, id 60303)
00:02:25.444987 202.108.221.51.80 > 172.16.161.166.24840: R 0:0(0) ack 1627914241 win 0 (ttl 110, id 32700)
00:02:59.476941 202.108.221.51.80 > 172.16.243.4.63767: R 0:0(0) ack 4179034113 win 0 (ttl 110, id 26912)
............Time Lapse............
23:59:45.063206 202.108.221.51.80 > 172.16.22.178.35077: R 0:0(0) ack 2298806273 win 0 (ttl 109, id 3025)


13th Shadow logs
00:00:17.300142 202.108.221.51.80 > 172.16.78.164.39970: R 0:0(0) ack 2619473921 win 0 (ttl 110, id 60932)
00:00:59.722188 202.108.221.51.80 > 172.16.133.209.4111: R 0:0(0) ack 269418497 win 0 (ttl 110, id 5391)
00:02:13.569329 202.108.221.51.80 > 172.16.45.7.18977: R 0:0(0) ack 1243676673 win 0 (ttl 109, id 6333)
............Time Lapse............
19:20:46.986293 202.108.221.51.80 > 172.16.226.91.59681: R 0:0(0) ack 3911254017 win 0 (ttl 109, id 14283)


14th Shadow logs
00:42:07.025158 202.108.221.51.80 > 172.16.148.178.29711: R 0:0(0) ack 1947140097 win 0 (ttl 109, id 9753)
00:42:29.565808 202.108.221.51.80 > 172.16.185.39.61707: R 0:0(0) ack 4044029953 win 0 (ttl 110, id 50169)
............Time Lapse............
23:58:37.761785 202.108.221.51.80 > 172.16.150.117.61966: R 0:0(0) ack 4061003777 win 0 (ttl 103, id 17638)

1. Source of trace:
These traces were obtained between our Internet border (from a monitoring point feed by three of our Border routers) and main CISCO 7500 internal router.
     
2. Detect was generated by:
Initial activity was noted on a Shadow hourly report. The Shadow logs provided were produced with a query to isolate the IP addresses involved. AscTCPDUMP output was obtained on some packets (snap length of 100bytes was collected on the sensor) to help identify the attacker.
     
3. Probability the source address was spoofed:
The host (victim) address does not resolve, however the host belongs to a network owned by ChinaNet - BJ (Beijing). It is also approximately 16 HOPS from our network. This puts the TTL at approximately 126 from the source host. A good assumption is that this is a WinNT IIS server under a prolonged denial of service attack. The source address does not appear to be spoofed. It would appear that the destination addresses (our network) are the addresses being spoofed in this example, as we are receiving the replies from the poor web server.
     
4. Description of attack:
At first glance this appears to be a minor attack. It must be noted however that only packets spoofed from our addresses (third party) are noted returning from the source host (victim) by our sensors. The source is most probably being hit by many machines and network addresses at the same time. Perhaps this is a politically motivated attack, hoping to create more damage between countries with differing governments than actually causing a concerned IT related incident.

It is difficult to determine the tool the real attacker is using. The apparent randomness of IP addresses used definitely leads to the belief that a tool is used to either craft the packets or a randomized list is being used as input.

Another anomaly noted is that the source does not resolve, is not serving anything on port 80, and does not respond to pings. It's as if it does not exist. This leads to another possible motive for this attack.

The intent could possibly have been a denial of service attack between the attacker and our network. It is practical to assume based on the traceroute performed and analytical correlation that the source was approximately 16 hops away though, which could place it in China. The fact that no response was solicited or noted from our networks (many of those targeted do not even exist) pretty much rules out a reconnaissance attempt. It is therefore assumed that this was purely a denial of service attack.
CVE-1999-0116
 
     
5. Attack mechanism:
The attacker sent TCP SYN packets to a host from a third parties IP address. This is determined by the responses from the intermediate host (victim) sent to the third party (our networks - victim 2). Usually in a scenario like this, many different attacking computers do this during the same time frame to tie up the intermediate victim's resources and deny service to it by others. This is known as SYN Flooding or Half open connections.
Due to the time period involved, 7 days long, it is assumed that this was a major attack which only involved our networks as one element.
 
     
6. Correlation:
Numerous tools were used for correlation. Traceroute was used to do some passive fingerprinting and validity checking of the source (victim). NSlookup was done on the host using NameSpace.org (URL below), and two logs (Shadow and TCPDUMP) were used.
www.namespace.org/search
traceroute@ee.lbl.gov
www.cert.org/advisories/CA-96.21.tcp_syn_flooding.html

7. Evidence of active targeting:
This detect proves active targeting of the source IP 202.108.221.51. Our networks were specifically configured within the attack, but it is unlikely that much thought was placed in this aspect.  If however, an attempt to create political tension between two countries was sought, this detect could be considered as active targeting.

8. Severity:

Target Criticality = 1

This third party  attack did not target specific hosts within our network. It actually did not  actively target our addresses with any apparent malice  intended.

Attack Lethality = 1

As this was not  targeted at our addresses with the intent to cause us damage, the attack  lethality is very low as well.

System Countermeasures =  3

Target systems are  well maintained and patched.

Network Countermeasures =  5

Intrusion Detection  Systems, well maintained firewalls, routers, and a current Security Policy.  Specifically, this attack does not cause collateral damage except to rob network  bandwidth. Reconfiguration of border routers to drop the victim would be an  option.

(1 + 1) - (3 + 5) = -6

Using the formula Severity = (Target  Criticality + Attack Lethality) - (System Countermeasures + Network  Countermeasures) the following severity has been  determined.



9. Defensive recommendation:
Reconfiguring the border routers to drop the victim's IP is one way to preserve our internal network bandwidth. Contacting the owner of the network being attacked to inform them of the ongoing attack would be a prudent decision. It is difficult to stop these types of activities. As our network is only minimally involved, and we did not respond, our router configurations would probably not be changed. The onus is on the owners of the web server to get their server running again and track down the attacker from what can be determined in the initial SYN packets.
     
10. Multiple choice test question:
Which Operating System does this packet most probably originate from given that the hop count back to host is 17?
     
04:46:40.799690 202.108.221.51.80 > 172.16.42.191.38159: S 333056621:333056621(0) ack 2500788225 win 16616 <mss 1460> (DF) (ttl 110, id 59480)
     
A. Windows 9x ttl 128
B. Cisco 3600 IOS Ver 12.0(7) ttl 255
C. OpenBSD 2.6 ttl 64
D. Linux RedHat 6.1 ttl 64

     
The correct answer is A. 110 + 17 = 127 which is closest to 128.

Assignment #2 - Evaluate an Attack

Evaluate an Attack

Overview
This evaluation is of L0pht Heavy Industriesí AntiSniff v1.02.1.  AntiSniff is a tool designed to find network interface cards (NICís) that are in promiscuous mode.  This is accomplished using various techniques such as comparing data gathered on network segments to previous historical data on the same flat, unswitched segments, and using crafted packets as stimuli to exploit deficiencies in the OS kernel, which when analyzed, indicate a promiscuous NIC.

There are numerous reasons for wanting to know who is running in promiscuous mode on your network.  Two such reasons are:

1.         Upon the successful compromise of a system, hackers regularly enter promiscuous mode in order to gather more reconnaissance on the network such as stealing telnet passwords passing back and forth on the internal network between trusted hosts.

2.         Possibly a disgruntled worker, industrial spy, or nosy contractor is carrying out unauthorized monitoring on the network for their own malicious reasons.

The Pros

Given the ability to track down these unwanted eavesdroppers, it is possible to gain initial indications of a compromised host or potentially malicious activity on your network.

As AntiSniff only detects machines with a TCP/IP stack, it is not capable of finding out where properly configured IDSí running in passive mode reside.  This greatly increases the likelihood that the tool will be used for legitimate purposes.

The Cons
 
This tool works best with a clean fingerprint of the computers to be monitored.  The larger the history the better.  This fingerprint also needs to be stored (either externally or as an .ass file).  A scan of a single host takes about 4 minutes using default settings, and chews up bandwidth on a 10Mbit connection.  As an example, on one of the scans, snort received 1702874 packets within this time frame and dropped 1422508 or 83.536% on a PII 266 with a 3Com 10/100 NIC.  A self imposed denial of service attack may ensue if active scanning occurs during peak hours.  Yet another limitation of this tool is realized when deployed on switched networks.  Sniffers only see traffic delivered through their interface on a switch, and as such do not integrate well on switched networks.  AntiSniff requires a degree of maintenance and administration to profit from its features.  It does not seem to be a tool that would be regularly used by system administrators, but rather one used during a security audit.

The Traces
 
The first trace provided 17MB of data in four minutes with only one host targeted. AntiSniff crafts packets down to the Medium Access Control (Data Link Layer) and as such, a capture including the ether frame was obtained.  Both Snort-1.6.3 on an NT4 system and TCPDump on a Linux 2.2.14 kernel were used to capture the traffic.  Numerous other captures were performed to isolate specific traffic generated by AntiSniff. 
  
Filters Used
 
The filter used for the SNORT capture was "snort -v -e > filename"
The filter used for the TCPDUMP capture was "tcpdump -v -e -n -w filename"

The Tests

DNS

The first test AntiSniff performs, attempts to generate a DNS  request from bogus traffic. Any systems that are noted doing an IP to name inverse resolution in response to this bogus traffic is flagged as being in promiscuous mode.  Reasoning is that a host doing a DNS query including the bogus IP must have been in promiscuous mode or it would not know about the bogus host and would not have queried for it.  According to L0pht, hackers may install tools that attempt the above stated action.

Snort Log (see  annex a for field description)
09/12-10:16:59.420396 22:22:22:22:22:22  -> 66:66:66:66:66:66 type:0x800 len:0x1F4
1.1.1.1:23 ->  2.1.1.1:23 TCP TTL:60 TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack: 0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:16:59.420712 66:66:66:66:66:66 -> 22:22:22:22:22:22  type:0x800 len:0x1F4
2.1.1.1:23 -> 1.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***A* Seq: 0x181CD¬ ¬  Ack:  0x303A¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:16:59.420995 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x1F4
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
******A* Seq: 0x303A¬ ¬  Ack:  0x181CE¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ¬ 



Note the impossible ethernet MAC addresses, the fake three way handshake, repeating ID and use of the well known port 23 (telnet).

ARP

The next test tries to take advantage of a flaw in Microsoftís older generic network interface card drivers.  A computer using one of these Microsoft drivers will respond to packets coming from broadcast ether frame address of ff:ff:ff:ff:ff:ff if the NIC is in promiscuous mode.  It should not however respond to an address of ff:00:00:00:00:00.  It turns out that only the first octet is checked and if it is 255 or 0xff, the packet will be dropped unless the computer is in promiscuous mode.  In this case, it is passed up the stack and processed accordingly.  If the IP address is correct for the computer, it will be processed, and a response generated, effectively indicating that the computer is in promiscuous mode. 

SNORT
09/12-10:20:15.779272 ARP who-has 192.168.30.5 tell 192.168.30.4
09/12-10:20:15.779446 ARP reply 192.168.30.5 is-at  0:0:86:1F:FB:B2
09/12-10:20:16.279546 ARP who-has 192.168.30.5  tell 192.168.30.4
09/12-10:20:16.279671  ARP reply 192.168.30.5 is-at 0:0:86:1F:FB:B2

TCPDUMP(see annex a for field description)
09:12:48.670862 eth0  M 0:1:2:3c:61:f1 1:0:0:0:0:0 arp 60: arp who-has 192.168.30.5 tell  192.168.30.4
09:12:48.670902 eth0 > 0:0:0:0:0:0  0:0:86:1f:fb:b2 arp 42: arp reply 192.168.30.5 (0:0:86:1f:fb:b2) is-at  0:0:86:1f:fb:b2 (0:1:2:3c:61:f1)
09:12:49.171064 eth0 M  0:1:2:3c:61:f1 1:0:0:0:0:0 arp 60: arp who-has 192.168.30.5 tell  192.168.30.4
09:12:49.171088  eth0 > 0:0:0:0:0:0 0:0:86:1f:fb:b2 arp 42: arp reply 192.168.30.5  (0:0:86:1f:fb:b2) is-at 0:0:86:1f:fb:b2 (0:1:2:3c:61:f1)



Interesting to note that SNORT translated the ARP requests into itís own format and did not include ethernet header even though the Ėe option was included with the command execution.  A TCPDUMP log, however, did include the ethernet headers and it can be seen that the ethernet address of the source is an odd number and represents a broadcast address.  See www.netsys.com/macaddr.html for a list of manufacturer MAC addresses.

Etherpings

This test is aimed at older Linux and NetBSD kernels.  It takes advantage of the fact that these older kernels did not look at the ethernet address when in promiscuous mode.  A crafted packet containing a bogus ethernet address, but a valid IP address would be passed to the kernel and handled if the machine was in promiscuous mode.  In normal operation this would never happen as the bogus ethernet address would ensure it was never looked at past layer two.

Snort
09/12-10:21:16.319220  0:1:2:3C:61:F1 -> 66:66:66:66:66:66 type:0x800 len:0x3E
192.168.30.4 -> 192.168.30.5 ICMP TTL:60 TOS:0x0 ID:51966¬  DF
ID:57857¬ ¬  Seq:19712¬  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:21:16.319305 0:1:2:3C:61:F1 -> 66:66:66:66:66:66  type:0x800 len:0x3E
192.168.30.4 -> 192.168.30.5 ICMP TTL:60  TOS:0x0 ID:51966¬  DF
ID:57857¬ ¬  Seq:19712¬  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



Snort received 45019 packets and dropped 30208(67.101%) packets.
Note the crafted destination ethernet address, repeating ID and sequence number.

ICMP Time Delta Test

This test works on the premise that a computer operating in promiscuous mode is not afforded the speed advantage offered to computers using their hardware for dropping unwanted packets.  AntiSniff will send very large amounts of data over the wire, destined to user configurable IP addresses.  Every so often a response will be solicited from a targeted machine and delays in response time will indicate the kernel of the tested machine is under increased processing load which can indicate it is in promiscuous mode.  Take for example that SNORT dropped 83% of packets destined to a different computer as indicated by a capture summary below.
 
Snort received 1702874 packets and dropped 1422508(83.536%) packets   
 
Breakdown by protocol:

TCP: 122172

(7.174%)

UDP: 45

(0.003%)

ICMP: 15422

(0.906%)

FRAGS: 0

(0.000%)

ARP: 99

(0.006%)

IPv6: 0

(0.000%)

IPX: 0

(0.000%)

OTHER:142628

(8.376%)



Th
is is an example to show just how much more load the logging computer was under during this scan.  There are four distinct phases used in determining latency as indicated by the headings before the log samples below.

Echo Responses with no flooding

Snort
09/12-10:33:04.609917  0:1:2:3C:61:F1 -> 0:0:86:1F:FB:B2 type:0x800 len:0x27A
192.168.30.4 -> 192.168.30.5 ICMP TTL:128 TOS:0x0 ID:23679
ID:273¬ ¬  Seq:1¬  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:33:04.610343 0:0:86:1F:FB:B2 -> 0:1:2:3C:61:F1 type:0x800  len:0x27A
192.168.30.5 -> 192.168.30.4 ICMP TTL:128 TOS:0x0  ID:7169
ID:273¬ ¬  Seq:1¬  ECHO REPLY
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



This tries to determine normal response times prior to putting the suspected promiscuous computer under increased load.  During flooding of different types, AntiSniff sends a legitimate ping to the suspect computer.  This is how it calculates the delta in latency during flooding.
  
"66" packet flooding

09/09-17:07:28.414574  0:1:2:3C:61:F1 -> 66:66:66:66:66:66 type:0x800 len:0x3E
192.168.30.4 -> 192.168.30.6 ICMP TTL:60 TOS:0x0 ID:51966¬  DF
ID:53248¬ ¬  Seq:19712¬  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



According to AntiSniff documentation:

SIXTYSIX creates packets that are comprised entirely of the hex value 0x66.  This is designed to not be accepted by any non-promiscuous mode host yet create data that is logged and captured by most normal use network monitoring tools such as tcpdump, snoop, etc.

No traffic was noted complying to this description within SNORT or TCPDUMP.

TCP SYN flooding

Snort
09/12-10:33:53.614659  22:22:22:22:22:22 -> 66:66:66:66:66:66 type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60 TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack: 0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:33:53.615477 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack:  0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:33:53.616291 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack:  0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



This method of flooding is done to labour promiscuous sniffers that operate on state. The theory is that the sniffer will notice the initial syn packet and monitor for following session packets in order to track state. A system doing this type of stateful logging will become taxed quickly under this type of flood and if this is the case latency, will become evident.

TCP flooding with three way handshake

Snort
09/12-10:33:21.913107  22:22:22:22:22:22 -> 66:66:66:66:66:66 type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60 TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack: 0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:33:21.913973 66:66:66:66:66:66 -> 22:22:22:22:22:22  type:0x800 len:0x5DB
2.1.1.1:23 -> 1.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***A* Seq: 0x181CD¬ ¬  Ack:  0x303A¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:33:21.914803 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
******A* Seq: 0x303A¬ ¬  Ack:  0x181CE¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



This flood is similar to a syn flood, but goes one step further by completing the three way handshake using bogus IP addresses.  This is done in the hopes of triggering more sophisticated IDS' and creating a scenario whereby they are taxed more heavily by having to log these entries and increasing latency which is detectable. 

Below is an example of a ping sent during flooding to calculate latency.  The example below was obtained from a scan with larger values entered into the parameters for the scan, against a Linux RedHat 6.2 system.

Snort
09/09-17:07:46.681833  0:1:2:3C:61:F1 -> 0:1:2:3C:61:E4 type:0x800 len:0x27A
192.168.30.4 -> 192.168.30.6 ICMP TTL:128 TOS:0x0 ID:32606
ID:273¬ ¬  Seq:0¬  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/09-17:07:46.681879 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x3C
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
******A* Seq: 0x303A¬ ¬  Ack:  0x181CE¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/09-17:07:46.681926 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x3C
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack:  0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/09-17:07:46.681973 66:66:66:66:66:66 -> 22:22:22:22:22:22  type:0x800 len:0x3C
2.1.1.1:23 -> 1.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***A* Seq: 0x181CD¬ ¬  Ack:  0x303A¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



Echo Test

Snort
09/12-10:38:16.269228  0:1:2:3C:61:F1 -> 0:0:86:1F:FB:B2 type:0x800 len:0x3C
192.168.30.4:1374 -> 192.168.30.5:7 UDP TTL:128 TOS:0x0 ID:42111
Len: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:38:16.269456 0:0:86:1F:FB:B2 -> 0:1:2:3C:61:F1 type:0x800  len:0x46
192.168.30.5 -> 192.168.30.4 ICMP TTL:128 TOS:0x0  ID:55809
DESTINATION UNREACHABLE: PORT UNREACHABLE
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



The echo test uses UDP pings.  The computer being flooded in this example does not listen on UDP port 7, and generated an ICMP type 3 message.

Following this activity more flooding is initiated as noted above during the ICMP Latency tests.  The reason for using UDP pings is to circumvent firewalls or other filtering devices that may drop ICMP responses from the targeted computer.  Again, legitimate pings are noted within the floods to determine latency.

PING DROP Test

Snort
09/12-10:39:41.842034  0:1:2:3C:61:F1 -> 0:0:86:1F:FB:B2 type:0x800 len:0x536
192.168.30.4 -> 192.168.30.5 ICMP TTL:128 TOS:0x0 ID:45439
ID:691¬ ¬  Seq:0¬  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:39:41.842785 0:0:86:1F:FB:B2 -> 0:1:2:3C:61:F1 type:0x800  len:0x536
192.168.30.5 -> 192.168.30.4 ICMP TTL:128 TOS:0x0  ID:7426
ID:691¬ ¬  Seq:0¬  ECHO REPLY
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



Then more syn flooding... 

Snort
09/12-10:39:42.442759  22:22:22:22:22:22 -> 66:66:66:66:66:66 type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60 TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack: 0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:39:42.443611 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack:  0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:39:42.444428 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x5DB
1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60  TOS:0x0 ID:51966¬  DF
**S***** Seq: 0x3039¬ ¬  Ack:  0x0¬ ¬  Win: 0x0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



with occasional latency checks

Snort
09/12-10:39:42.965838  0:1:2:3C:61:F1 -> 0:0:86:1F:FB:B2 type:0x800 len:0x536
192.168.30.4 -> 192.168.30.5 ICMP TTL:128 TOS:0x0 ID:47999
ID:691¬ ¬  Seq:0¬  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/12-10:39:42.966710 0:0:86:1F:FB:B2 -> 0:1:2:3C:61:F1 type:0x800  len:0x536
192.168.30.5 -> 192.168.30.4 ICMP TTL:128 TOS:0x0  ID:10242
ID:691¬ ¬  Seq:0¬  ECHO REPLY
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+



The ping drop test floods the target computer with ICMP pings in an attempt to measure latency by comparing consecutive response times.  This is followed again by three way handshake flooding, syn flooding, 66 packet flooding, and ICMP pings intermixed.

SNORT lost a large amount of traffic as indicated by the summary listed below.

Snort received 76677 packets and dropped 72004(93.906%) packets 
 
Breakdown by protocol:

TCP: 4099

(5.346%)

UDP: 3

(0.004%)

ICMP: 100

(0.130%)

FRAGS: 0

(0.000%)

ARP: 4

(0.005%)

IPv6: 0

(0.000%)

IPX: 0

(0.000%)

OTHER: 6

(0.008%)



Through the above measures, it is possible to find compromised hosts or other eavesdroppers that are not authorized on the network.
The below screenshots offer a glimpse of the software.
AntiSniff v1.02.1 Network Config


AntiSniff v1.02.1 Reports

 Assignment #3 - Analyze This

Suspected Compromises
 
1.   Telnet attempts from 159.226.45.108 to MY.NET.6.7 indicate a brute force attempt to gain access to the host.  There were also 1080 connection attempts to this host which indicate it is involved in IRC either as a client or proxy, connections to port 25 were made, as well as Auth Service.  It is possibly a multipurpose server handling mail and authentication services.  On Aug 5th at 1859hrs a ďTELNET-Login IncorrectĒ was triggered against this box.  If this was not a newly created Snort rule, this indicates that the box is compromised based on the other Telnet connections that did not trigger this alarm, and requires immediate attention.  This being said however, the possibility that host 159.226.45.108 successfully logged in within very short periods of time (eg. 1 second apart) is unlikely.  It would appear as if a new Snort rule was put in place on 5th Aug.

DateHour

Min

Sec

Sep1

Signature

Sep2

SourceIP

SourcePort

Sep3

DestIP

DestPort

08/04/2021

26

22

[**]

Watchlist 222 NET-NCFC

[**]

159.226.45.108

1028

->

MY.NET.6.7

23

08/05/2018

59

23

[**]

IDS127 - TELNET - Login Incorrect

[**]

MY.NET.6.7

23

->

38.30.171.95

1223



2.   Another Telnet attempt that appears to have been successful was from a cable modem user based in Minnesota.  It is suspected that this was an administrator for the site.  Based on analysis, it is assumed that this is a Military Network, due to the identification of targets of interest and availability of resources (i.e. numerous mail servers etc).  This telnet session was successful and did not trigger the "TELNET-Login Incorrect" alarm, but a newer alarm "IDS08-TELNET-daemon-active".  Telnet sends passwords in the clear and this host must now be assumed compromised since anyone between 24.25.111.117 and the host could have sniffed it.

DateHour

Min

Sec

Sep1

Signature

Sep2

SourceIP

SourcePort

Sep3

DestIP

DestPort

ID

08/05/2019

3

45

[**]

IDS08 - TELNET - daemon-active

[**]

MY.NET.99.51

23

->

24.25.111.117

1029

47544



3.    FTP traffic from watched networks (AREL-NET Israel 212.179.0.0/16 and Computer Network Center Chinese Academy of Sciences 159.226.0.0/16) indicates many file transfers took place.  This requires further investigation of the hosts involved.  Correlation was done with the "FTP-bad-login" alarm generated.  Reasoning is that if this rule existed from the day the sensor was installed, this would have triggered for all other FTP servers unless anonymous FTP is enabled, or every user had a valid account and made no errors during authentication.  It is suspected that this rule was added at the same time as the above "TELNET-Login Incorrect" rule.

DateHour

Min

Sec

Sep1

Signature

Sep2

SourceIP

SourcePort

Sep3

DestIP

DestPort

05/08/2018

58

19

[**]

FTP-bad-login

[**]

MY.NET.145.18

21

->

151.201.240.226

1074

06/27/2006

40

24

[**]

Watchlist 220 ILISDNNET990517

[**]

212.179.101.218

1258

- >

MY.NET.181.88

20



This situation does require more investigation.  A definite transfer of data occurred between 212.179.101.218 and MY.NET.181.88.  As stated above, either anonymous access is enabled (which should be dealt with in the security policy) or an account has been compromised.  There are also indications that this host was used for IRC.

DateHour

Min

Sec

Sep1

Signature

Sep2

SourceIP

SourcePort

Sep3

DestIP

DestPort

ID

06/27/2006

37

9

[**]

Watchlist  220 ILISDNNET990517

[**]

212.179.101.218

1219

->

MY.NET.181.88

21

25395

06/27/2006

37

9

[**]

Watchlist  220 ILISDNNET990517

[**]

212.179.101.218

1220

->

MY.NET.181.88

20

25396



Dangerous Traffic
 
1.    The suspected use of ICQ (noted by connections from 205.188.153.111 fes-d015.icq.aol.com on port 4000) by MY.NET.217.126. (2240 hits in 3 days) was noted.  The logs indicate it was installed between the 1st Aug and 3rd Aug.  The connection is active 24hrs per day, which indicates shared usage from this destination host.  Perhaps it is used by shift workers and is a required service.  None the less, running this opens a system to numerous exploits, as the following links will show:

www.arcwebserv.com/jumpsite/icqattack.html
home.t-online.de/home/TschiTschi/icq_dedrohungen.htm

DateHour

Min

Sec

Signature

SourceIP

SourcePort

DestIP

DestPort

04/08/2000

38

19

Attempted Sun RPC high port  access

205.188.153.111

4000

MY.NET.217.126

32771



2.    The traffic to port 25 on MY.NET.100.230 is noteworthy.  Time was taken to specify filters to alert us of traffic including the Computer Network Center Chinese Academy of Sciences.  This requires more investigation of the suspect host.  Why are connections from a suspect network being made, with such frequency, to this host?  Authentication services and mail are being probed.  What did the offender find out and why is this host connecting from high ephemeral ports back to the network of interest?  It is interesting to see that this network is busiest during government work hours with a dip during lunchtime (Beijing is 11hrs behind EST).

SMTP connections by hour


3.     The scan by MY.NET.5.37 to find hosts listening on port 5632 is intrusive.  This destination port is associated with PCAnywhere.  If it is running on the network, it should be monitored.  PCAnywhere by default scans for other hosts on the network it is installed on when trying to make a connection (i.e. a udp 5632 broadcast).  This is the case here as only the MY.NET.5.0/24 network was targeted.

ID

Month

Day

Time

SourceIP

Src  Port

Sep1

DestIP

Dest  Port

Proto

139068

Aug

10

06:35:11

MY.NET.5.37

2600

->

MY.NET.5.247

5632

UDP



4.      The use of Napster by employees is another dangerous activity.  Napster opens up shares on the host it is installed on.  This software acts as both client and server applications in one.

5.     "SMB name wildcard" packets were noted incoming on the network.  No response to this activity was noted, but may have been present since we are only seeing traffic based on alarms.  These types of packets should be dropped at the firewall.  More information is available at:

www.signaltonoise.net/library/cifs.htm

DateHour

Min

Sec

Sep1

Signature

Sep2

SourceIP

Src  Port

Sep3

DestIP

Dest  Port

04/08/2016

23

34

[**]

SMB Name Wildcard

[**]

208.16.237.10

137

->

MY.NET.15.127

137

04/08/2016

23

50

[**]

SMB Name Wildcard

[**]

132.201.232.167

137

->

MY.NET.15.127

137



6.      Telnet is active on this network.  This should be replaced with Secure Shell.
  
Recommendations
 
1.      The SYN/FIN scans breached the firewall.  A statefull filtering firewall should be put into service. This would eliminate large portions of log data (22.5% of traffic) and protect the network from malicious connection attempts and mapping via this method.  Leaving the Snort rule in place would still allow monitoring for anomalies and internal probes of this nature.
  
2.      Adjusting or enforcement of the acceptable security policy is needed to disallow ICQ, IRC, and Napster traffic.  If these are deemed as necessary services by management then connections through a proxy server that is patched, monitored, and secured should be enforced.  There was a large amount of activity related to monitored networks using these services.  Generally, from experience in the field, these are not accepted services in corporate or government work environments.
  
3.      Continued monitoring of the host MY.NET.1.3.  This DNS server appears to be heavily loaded, but did not provide any other concerns.  Perhaps load balancing may be required.  Internal users could use the present secondary DNS server located at MY.NET.101.89 and external queries could be made to MY.NET.1.3.  This enhances the security posture.
  
4.      Shutting down Authentication Services (port 113) on computers that do not require it would be prudent.  They have little value, slow connections down, and may provide account details for the machine.  Unless they are required they should be edited out of the /etc/inetd.conf file.  Numerous probes were done to servers running this service from networks of interest.
  
5.      Employing the ACL's on the border router to drop traffic to port 53 except destined to the legitimate DNS server should be implemented.
  
6.      The large quantity of ICMP traffic destined for MY.NET.140.9 indicates that there could have been a possible DOS attack against it.  The policy for filtering ICMP incoming and outgoing should be reviewed.  While it does not appear to have been of a magnitude that would have affected the operation of this host, it did comprise a large portion of the log data.
  
7.      Reducing the number of mail servers would be prudent.  Judging from the number of alarms present, the network has too many.  Knowing the exact number of hosts on this Class B network, and their usage would clarify this.  (The mail servers appear to be MY.NET.253.41 (1903 hits to port 25), MY.NET.253.42 (522 hits), and MY.NET.253.43 (582 hits).  MY.NET.6.7 (41 hits) and MY.NET.6.7 (18 hits) appear to be smaller departmental mail servers.  While there are theoretically 65534 hosts on this Class B network, a more accurate estimate on this sniffed segment is 5000 hosts.
  
8.      SNMP Public Access strings were noted on the network.  A suspected management device at MY.NET.101.192 is the destination of these packets.  Generally speaking, having a Public Group Membership is considered a poor security practice.
  
9.      To narrow the data down and aid in manageability, Snort rules should be tweaked.  For instance, the "Wingate 8080 Attempt" signature could be removed (4% of traffic).
  
Bid Ground Rules
 
There were 52 individual hosts that triggered alarms originating from MY.NET.0.0/16. Theoretically, there is room for quite a large number of hosts (65534).  Based on the fact that 18 Class C networks appeared, it is assumed that there are approximately 4572 hosts being monitored by these Snort sensors.  If the alarm sensor was placed in an effective position than this count may prove to be an accurate number of hosts to aid in the bid process.

It is also assumed that there are no Network Security Specialists presently employed on-site by this organization.
 
The Bid
 
On site monitoring should be conducted due to the sensitive nature of your companies business.  A staff of one supervisor and three analysts have been identified as sufficient to handle up to 5000 hosts.  They will aid present system administrators in enforcing a new security policy, written by our company, upon its acceptance.  A Threat Risk Assessment will be presented prior to any policy change, and updated quarterly.  In order to effectively monitor and maintain the confidentiality, integrity, and availability of data on this network, the following resources are initially required.

Description

Qty

Price

Amount

External Sensors

2

 $1,500.00

 $3,000.00

Internal Sensors

4

 $1,500.00

$6,000.00

Analysis Stations

2

$2,000.00

$4,000.00

Statefull Filtering Firewall

1

$ 6,000.00

$6,000.00

Proxy for Other Traffic

1

$6,000.00

$6,000.00

Wages Analyst

3

$45,000.00

$135,000.00

Wages Supervisor

1

$ 75,000.00

$75,000.00

Lodging/Furniture/Fixtures

1

$29,000.00

$29,000.00

Local Personnel Training Program

1

$100,000.00

$100,000.00

Host Premium

4572

$5.00

$22,860.00

 

Total

$386,860.00



Recurring cost for first year extension:

Description

Qty

Upkeep

Pre-depreciation

Dep %/Upkeep/Inflation

Amount

External Sensors

2

$1,500.00

$3,000.00

30.00%

$900.00

Internal Sensors

4

$1,500.00

$6,000.00

30.00%

$1,800.00

Analysis Stations

2

$2,000.00

$4,000.00

30.00%

$1,200.00

Statefull Filtering Firewall

1

$6,000.00

$6,000.00

30.00%

$1,800.00

Proxy for Other Traffic

1

$6,000.00

$6,000.00

30.00%

$1,800.00

Wages Analyst

3

$45,000.00

$135,000.00

4.20%

$140,670.00

Wages Supervisor

1

$75,000.00

$75,000.00

4.20%

$78,150.00

Lodging/Furniture/Fixtures

1

$29,000.00

$29,000.00

20.00%

$5,800.00

Local Personnel Training Program

1

$100,000.00

$100,000.00

30.00%

$30,000.00

Host Premium

4572

$5.00

$22,860.00

4.20%

$23,820.12

 

 

 

 

Total

$285,940.12



Our company respectfully requests an answer to this bid by 1 October 2000.

Regards,
Christopher James French

 Assignment #4 - Analysis Process

Analysis for assignment three was done using numerous tools.  Due to the sheer amount of data present, and the awkward way in which it is presented, it was determined that another format was necessary to convert it to that was more useable.

Initially, this data was sorted on a Unix system primarily using grep.  Writing some Perl scripts to parse the data into fields was considered (have some lying around already), but the more powerful features of a COTS database was desired.  The more manual Unix option was abandoned at this time and the files were ported over to Microsoft.

The Snort logs were opened in MS Word and large "Replace All" operations were performed in order to insert delimited values between fields that were deemed as necessary to separate for querying later in a database.  These files were split into a size that would not exceed 65535 entries in MS Excel, and saved in a delimited format.  They were then opened in MS Excel, taking advantage of it's ability to handle multiple field delimiters during import.  Once imported, fields were defined and data aligned based on large sorts. These were then saved with a singular delimiter value (i.e. a comma), in delimited format.  Once  the files were prepared they were imported into MS Access.  A few custom queries, including "Make Table Queries" and "Crosstab Queries" were created.  These queried tables were saved for future reference (quick and dirty).

Then any specific data could be correlated easily.  The process of converting the data to a readable format took approximately six hours.  Due to the limitations of MS Access and its inability to handle data over 2GB in size, this would be a poor choice for analyst positions.  MySQL, Oracle, or another database would be best for an operational analysis tool.

MS Excel was used for the generation of charts.

Most analysis done was based on the TCP Quad, or the Source IP, Source Port, Destination IP, and Destination Port.  Time is an important factor too, and this field was included.  Once a general picture of the network and the traffic on it was obtained, more in-depth queries were performed, which included supplementary NSLookups, a traceroute or two, time zone checks, and augmented signature information was obtained.

Screenshots:
Destination Hosts by Number of Alarms Chart
Hosts of Interest by Volume of Traffic

Ports of Interest Hit by MY.NET.100.230 Pie Chart                           Find Duplicates Query Results

Ports of Interest Find Duplicates Query

The Database in action

Database in action

Annex A
Log File Field Descriptions:

 CISCO Secure IDS

Example:

4,1565662,2000/09/13,16:37:04,2000/09/13,12:37:04,10008,5,5000,OUT,IN,1, 3000,80,TCP/IP,205.158.26.242,172.16.0.119,80,50289,0.0.0.0,2849858975

Field Description Sample Value

Message Type

1=IP log, 2=error msg,  3=command msg, 4=event message

4

Record #

starts at 1.000.000 and  increases by one for each time sensord/packetd is started.

1565662

Global Date

This is the date related to Universal Time  Code (UTC) in yyyy/mm/dd format.

2000/09/13

Global Time

This is the time in UTC in HH:mm:ss  format.

16:37:04

Local Date

This is the local date in yyyy/mm/dd  format.

2000/09/13

Local Time

This is the local time in HH:mm:ss  format.

12:37:04

Application ID

This is the ID of the application  responsible for the alarm (sensord is 10001).

10008

Host ID

This is the unique ID of the sensor that  generated the alarm.

5

Organization ID

The unique organization ID that this  sensor belongs to.¬  Alarms are forwarded to the Director for this  organization.

5000

Source Direction

This is the direction in which the sensor  determines the source IP is in related to the alarm and owned  networks.

OUT

Destination  Direction

This is the direction in which the sensor  determines the destination IP is in related to the alarm and owned  networks.

IN

Alarm Level

This is the level this alarm has been set  to trigger at. Values are from 1-5 with 5 being the highest.

1

Signature ID

The ID of the filter or signature that  caused this alarm.

3000

Sub-Signature ID

If a sub-signature ID has been configured,  which one triggered this alarm.

80

Protocol

This indicates what protocol suite was  detected.

TCP/IP

Source IP

The source IP address involved with the  alarm.

205.158.26.242

Destination IP

The destination IP  address involved with the alarm.

172.16.0.119

Source Port

The source  port

80

Destination  Port

The destination  port

50289

Network Device Address reporting alarm

This is the address of  additional equipment configured to work with CISCO Secure IDS such as routers,  that provide alarms.  In this case it did not come from one of these  devices.

0.0.0.0

Alarm  Detail

This is related to the  capture of payload data or context.

2849858975

 TCPDUMP

Example:

 

12:33:38.339480  172.16.0.119.50289 > 205.158.26.242.www: S 2864488374:2864488374(0) win 8760  <mss 1460> (DF)

Field Description Sample Value

Time

Sensors local computer time, logged in  HH:mm:ss.milisec format.

06:57:50.734869

Source IP

The source IP address logged.

63.197.4.191

Source Port

The source port.

111

Seperator

>

Destination IP

The destination IP address logged. If -n  switch is not used it will be resolved if possible as seen in the sample  value.

host1.goodguys.com

Destination Port

The destination port.

111

Flag Set

URG, ACK, PSH, RST, SYN, FIN or any  combination

SF

Sequence #

Identifies the sequence in which packets are received. They  are determined by the host and number 1 up from this initial sequence number for  the same connection for every packet sent until termination of that  session.

665720017:6657200 17

Size of Data

This is the number of bytes sent in this  packet

(0)

Window Size

This is the amount of buffer space that  will be alloted for the reconstruction of packets received out of order.¬  It may  be negotiated.

1028

Maximum Segment  Size

This is the maximum size of data in bytes  that may be sent to the host.

1460

Fragmentation

This field is either set to on or off. DF  means don't fragment.

DF

The Hex and ASCII are collected and  displayed depending on switches used to initiate the caputre.  Recommended  reading for further TCP/IP packet breakdown is TCP/IP Illustrated, Volume 1 by  Richard Stevens, ISBN  0-201-63346-9

 ARGUS

Example:

Fri 06/09 19:33:39 tcp  195.117.123.171.1558 <| 10.0.223.22.53 1 1 0 0 RST

Field Description Sample Value

Day

Day of the week.

Fri

Date

Date of the log entry in mm/dd  format.

06/09

Time

Local time of the log entry in HH:mm:ss  format.

19:33:39

Protocol

The protocol logged, i.e. udp,  tcp.

tcp

Source IP

The source IP address logged.

195.117.123.171

Source Port

The source port.

1558

Direction

Statefull direction.

<|

Destination IP

The destination IP address  logged.

10.0.223.22

Destination Port

The destination port.

53

Packets

The number of packets noted for both  source and destination IP respectively.

1 1

Bytes

The number of bytes noted for both source  and destination IP respectively.

0 0

Status

The status of the session, example  RST=reset, TIM=time out.

RST

 Shadow

Example:

06:57:50.734869  63.197.4.191.111 > host1.goodguys.com.111: SF 665720017:665720017(0) win  1028

Field Description Sample Value

Time

Sensors local computer time, logged in  HH:mm:ss.milisec format.

06:57:50.734869

Source IP

The source IP address logged.

63.197.4.191

Source Port

The source port.

111

Seperator

>

Destination IP

The destination IP address logged. If -n  switch is not used it will be resolved if possible as seen in the sample  value.

host1.goodguys.com

Destination Port

The destination port.

111

Flag Set

URG, ACK, PSH, RST, SYN, FIN or any  combination

SF

Sequence #

Identifies  the sequence in which packets are received. They are determined by the host and  number 1 up from this initial sequence number for the same connection for every  packet sent until termination of that session.

665720017:6657200 17

Size of Data

This is the number of bytes sent in this  packet

(0)

Window Size

This is the size of a packet that may be  handled during communications by the hosts involved. It may be  negotiated.

1028

 Snort Lightweight IDS

Example:

09/12-10:16:59.420396 22:22:22:22:22:22 -> 66:66:66:66:66:66  type:0x800 len:0x1F4 1.1.1.1:23 -> 2.1.1.1:23 TCP TTL:60 TOS:0x0  ID:51966  DF**S***** Seq:  0x3039  Ack: 0x0  Win: 0x0

Field

Description

Sample Value

Day and  Month

The Day and month of the  capture.

09/12

Time

Sensors local computer time, logged in  HH:mm:ss.milisec format.

10:16:59.420396

Src Ethernet Address

The address in hex (MAC) from originating  host.

22:22:22:22:22:22

Seperator

->

Dest Ethernet Address

The address in hex (MAC) of destination  host.

66:66:66:66:66:66

Type

Value determined from 10 bits (hardware, proto,  size) of ether frame.Value of an IP datagram (0x0800)

0x800

Length

Total length of the IP datagram.

0x1F4

Source  IP

The source IP address  logged.

1.1.1.1

Source  Port

The source port.

23

Seperator 

->

Destination  IP

The destination IP address  logged. If -n switch is not used it will be resolved if possible as seen in the  sample value.

2.1.1.1

Destination  Port

The destination  port.

23

Protocol

The protocol used.

TCP

Time To Live

This is the number of hops remaining before the  packet ceases to be routed.

60

Type of Service

Values Min Delay, Max Throughput, Max Reliability,  Min Cost, or None. (0x0 = None)

0x0

Fragmentation

This field is either set to on or off. DF means  don't fragment. (DF means don't fragment)

DF

ID

This is the identification number.

51966

Flag Set

URG, ACK, PSH, RST, SYN, FIN or  any combination

**S*****

Sequence  #

Identifies the sequence in which packets are received. They  are determined by the host and number 1 up from this initial sequence number for  the same connection for every packet sent until termination of that session. (in  hex)

0x18CD

Acknowledgement  Sequence #

Same as above sequence # except  from destination host.

0x303A

Window  Size

This is the amount of buffer  space that will be alloted for the reconstruction of packets received out of  order.  It may be negotiated.

0x0

Different switches will produce different  output. This example used the -e switch to record ethernet headers  too.Recommended reading for further TCP/IP packet breakdown is TCP/IP  Illustrated, Volume 1 by Richard Stevens, ISBN 0-201-63346-9


Non-Active Sitemap

Copyright © 2000-2014 Whitehats.ca
Contact Information 519.221.9132 : Web Contact webmaster@whitehats.ca