[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect JeremyScott

Smith, Donald Donald.Smith at qwest.com
Fri Jul 2 14:55:16 GMT 2004



Donald.Smith at qwest.com GCIA 
I reserve the right to be wrong but don't exercise it too often.


> -----Original Message-----
> From: intrusions-bounces at lists.sans.org 
> [mailto:intrusions-bounces at lists.sans.org] On Behalf Of 
> jscott at rolenstarsupply.com
> Sent: Thursday, July 01, 2004 4:55 PM
> To: intrusions at incidents.org
> Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical 
> Detect JeremyScott
> 
> 

Not very much detail. It makes it harder later to draw conclusions.


> Network Detect 2:  Proxy scan
>  
> 
> Jun  20  00:00:00  tcp    216.232.9.229(1422)        
> xxx.xxx.xxx.231(3127),       denied
> 
> Jun  20  00:00:06  tcp    220.99.138.166(4867)       
> xxx.xxx.xxx.35(3127),        denied
> 
> Jun  20  00:00:08  tcp    220.99.138.166(4738)       
> xxx.xxx.xxx.37(3127),        denied
> 
> Jun  20  00:00:08  icmp   217.88.124.253             
> xxx.xxx.xxx.221              denied
> 
> Jun  20  00:00:14  tcp    220.99.138.166(3208)       
> xxx.xxx.xxx.35(3128),        denied
> 
> Jun  20  00:00:16  tcp    216.232.9.229(1690)        
> xxx.xxx.xxx.231(1080),       denied
> 
>  
> 
> 1.  Source of Trace:
>  
> 
> This was taken from the external router log produced on my 
> company network.  Our intrusion detection is within the 
> external router; therefore, no other logs are available to 
> correlate the data.  The internal IP addresses have been 
> obfuscated for security reasons.  
> 
>  
> 
> 2.  Detect was generated by:
>  
> 
> Self observation of the external router logs pulled on a 
> daily basis.  Looking at the logs for signs of malicious 
> behavior by hand can be tedious but there can also be a 
> wealth of knowledge in what is happening just outside your 
> border.  Here is a compiled example of the scan:
> 
>  
> 
> Access Attempts logged By MY_ROUTER
> 
> Mon  Day Time      Type   Source Address (Port)      
> Destination Address (Port)
> 
> ---  -- 
> 
> Jun  20  00:00:06  tcp    220.99.138.166(4867)       
> xxx.xxx.xxx.35(3127),        denied 
> 
> Jun  20  00:00:06  tcp    220.99.138.166(4867)       
> xxx.xxx.xxx.35(3127),        denied
> 
> Jun  20  00:00:06  tcp    220.99.138.166(4867)       
> xxx.xxx.xxx.35(3127),        denied
> 
> Jun  20  00:00:22  tcp    220.99.138.166(3486)       
> xxx.xxx.xxx.35(1080),        denied
> 
> Jun  20  00:00:40  tcp    220.99.138.166(4068)       
> xxx.xxx.xxx.36(3128),        denied
> 
> Jun  20  00:01:01  tcp    220.99.138.166(4738)       
> xxx.xxx.xxx.37(3127),        denied
> 
> Jun  20  00:01:28  tcp    220.99.138.166(3825)       
> xxx.xxx.xxx.40(3128),        denied
> 
> Jun  20  00:01:36  tcp    220.99.138.166(4105)       
> xxx.xxx.xxx.40(1080),        denied
> 
> Jun  20  00:01:44  tcp    220.99.138.166(4382)       
> xxx.xxx.xxx.41(3127),        denied
> 
> Jun  20  00:01:52  tcp    220.99.138.166(4869)       
> xxx.xxx.xxx.41(3128),        denied
> 
> Jun  20  00:01:58  tcp    220.99.138.166(3825)       
> xxx.xxx.xxx.40(3128),        denied
> 
> Jun  20  00:02:04  tcp    220.99.138.166(4105)       
> xxx.xxx.xxx.40(1080),        denied
> 
> Jun  20  00:02:24  tcp    220.99.138.166(3209)       
> xxx.xxx.xxx.41(1080),        denied

> 
> Jun  20  00:02:40  tcp    220.99.138.166(3507)       
> xxx.xxx.xxx.42(3127),        denied
> 
> Jun  20  00:02:53  tcp    220.99.138.166(4053)       
> xxx.xxx.xxx.42(1080),        denied
> 
> Jun  20  00:03:02  tcp    220.99.138.166(4326)       
> xxx.xxx.xxx.43(3127),        denied

Look at the source and dst ports notice anything?
There appears to be some "near" matches (1st and forth digit matching.

> 
> Jun  20  00:03:04  tcp    220.99.138.166(3698)       
> xxx.xxx.xxx.44(3128),        denied
> 
> Jun  20  00:03:11  tcp    220.99.138.166(4727)       
> xxx.xxx.xxx.43(3128),        denied
> 
> Jun  20  00:03:16  tcp    220.99.138.166(3427)       
> xxx.xxx.xxx.44(3127),        denied
> 
> Jun  20  00:03:28  tcp    220.99.138.166(3698)       
> xxx.xxx.xxx.44(3128),        denied
> 
> Jun  20  00:03:33  tcp    220.99.138.166(3970)       
> xxx.xxx.xxx.44(1080),        denied
> 
> Jun  20  00:03:52  tcp    220.99.138.166(4247)       
> xxx.xxx.xxx.45(3127),        denied
> 
> Jun  20  00:04:00  tcp    220.99.138.166(4629)       
> xxx.xxx.xxx.45(3128),        denied
> 
> Jun  20  00:04:17  tcp    220.99.138.166(3345)       
> xxx.xxx.xxx.46(3127),        denied
> 
> Jun  20  00:04:30  tcp    220.99.138.166(3902)       
> xxx.xxx.xxx.46(1080),        denied
> 
> Jun  20  00:04:37  tcp    220.99.138.166(4176)       
> xxx.xxx.xxx.47(3127),        denied
> 
> Jun  20  00:04:48  tcp    220.99.138.166(4969)       
> xxx.xxx.xxx.47(1080),        denied
> 
> Jun  20  00:05:04  tcp    220.99.138.166(3554)       
> xxx.xxx.xxx.48(3128),        denied



> 
>  
> 
> 3.  Probability the source address was spoofed:
>  
> 
> Since there were no other logs to correlate the data to, I 
> can't tell if the packets have any signs of crafting.  
> However, because of the ports that are being scanned the 
> source address is probably real.

Headers would be helpful!

> 
>  
> 
> Source Address - The source address is 220.99.138.166.  If 
> you do a whois on the IP address, you will be returned with 
> the following information from APNIC.
> 

Very difficult to read you might want to reformat. It was all run
together before I responded.

>  
> 
>  % [whois.apnic.net node-1]% Whois data copyright terms    
> http://www.apnic.net/db/dbcopyright.htmlinetnum:      
> 220.96.0.0 - 220.99.255.255netname:      OCN-JPNIC-JPdescr:   
>      OCN Provided By NTT-Communications which is ISPdescr:    
>     in Chiyoda-ku, Tokyo, Japancountry:      JPadmin-c:      
> JNIC1-APtech-c:       JNIC1-APremarks:      
> ************************************************remarks:      
> Allocated to JPNIC member. Authoritativeremarks:      
> information regarding assignments and allocationremarks:      
> made from within this block can also be queriedremarks:      
> at whois.nic.ad.jp. To obtain an English outputremarks:      
> query whois -h whois.nic.ad.jp x.x.x.x/eremarks:      Email 
> address for spam or abuse complaints : 
> abuse at ocn.ad.jpremarks:      
> ************************************************mnt-by:       
> MAINT-JPNICmnt-lower:    MAINT-JPNICchanged:      
> hm-changed at apnic.net 20020904changed:      ip-apnic at nic.ad.jp 
> 20040413status:       ALLOCATED PORTABLEsource:       
> APNICrole:         Japan Network Information Centeraddress:   
>    Kokusai-Kougyou-Kanda Bldg 6F, 2-3-4 Uchi-Kandaaddress:    
>   Chiyoda-ku, Tokyo 101-0047, Japancountry:      JPphone:     
>    +81-3-5297-2311fax-no:       +81-3-5297-2312e-mail:       
> hostmaster at nic.ad.jpadmin-c:      SS13-APtech-c:       
> SY7-APnic-hdl:      JNIC1-APmnt-by:       MAINT-JPNICchanged: 
>      apnic-ftp at nic.ad.jp 19990629changed:      
> ip-staff at nic.ad.jp 20030806source:       APNICinetnum:      
> 220.99.128.0 - 220.99.255.255netname:      PLALAdescr:        
> Plala Networks Inc.country:      JPadmin-c:      
> MN2905JPtech-c:       HS3694JPremarks:      This information 
> has been partially mirrored by APNIC fromremarks:      JPNIC. 
> To obtain more specific information, please use theremarks:   
>    JPNIC whois server at whois.nic.ad.jp. (This defaults 
> toremarks:      Japanese output, use the /e switch for 
> English output)changed:      apnic-ftp at nic.ad.jp 
> 20030203remarks:      This information has been partially 
> mirrored by APNIC fromremarks:      JPNIC. To obtain more 
> specific information, please use theremarks:      JPNIC whois 
> server at whois.nic.ad.jp. (This defaults toremarks:      
> Japanese output, use the /e switch for English 
> output)changed:      apnic-ftp at nic.ad.jp 20040609source:       JPNIC 
> 
> In that it is a valid IP address according to APNIC and the 
> ports that are being probed may return some type of response 
> to allow the hacker to gain access to the system leads me to 
> believe that the IP address is not spoofed.

Did you notify the abuse department listed above? 

> 
>  
> 
> 4.  Description of attack:
>  
> 
> The attack is obviously a scan for Socks and squid proxies in 

YES
> attempt to locate a compromised system or one that is running 
Compromised?

> the service to exploit possible vulnerabilities within the service.
> 
>  
> 
> A CVE that covers the squid proxy vulnerability can be found 
> at the following URL: 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0068 
> 
>  
> 
> A CAN, which is under review at this time, that covers the 
> socks proxy vulnerability can be found at the following URL:  
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0315 
> 
>  
> 
> Along with the proxies, the attacker appears to be probing 
> for port 3127.  This port is left open as a back door by the 
> myDoom virus[1] which in future could be an avenue for a 
> denial of service attack in the future, according to CERT at 
> http://www.cert.org/incident_notes/IN-2004-01.html. 

Some servers scan for proxies to prevent spammers from using open
proxies to send mail to them.
Did you check and see what that ip is?


> 
>  
> 
> 5.  Attack mechanism:
>  
> 
> The attacker is probing the network in search of responding 
> ports.  Since there are no other logs to correlate with, I 
> can only assume that the TCP packets that are being sent are 
> to elicit some response to find a listening or compromised 
> host.  For example, the attacker sends an unsolicited TCP 
> packet with the ACK flag set.  The normal response would be 
> for the host to respond back with RST.  If that is indeed the 
> case, the attacker now knows that:  1) the host is alive and 
> listening, and 2) there is no filtering in place.

Again details on the packets might have given you a better clue as to
what was going on.

> 
>  
> 
> If the attacker receives no response then he can assume: 1) 
> some type of filtering is in place, or 2) that the host is not alive.

Any other possibilities?

> 
>  
> 
> If the attacker receives the response that is being solicited 
> then he can attempt to exploit the vulnerabilities with a 
> buffer overflow using specially crafted packets.  In the case 
> of the back door left by the myDoom virus, the attacker could 
> possible take control of that system to launch a denial of 
> service attack.

> 
>  
> 
> 6.  Correlations:
>  
> 
> I found a posting at 
> http://lists.sans.org/pipermail/unisog/2004-March/006955.php 
> that states that they had seen some scans, particularly on 
> the weekends, just a couple of months back.  I was unable to 
> see any other postings to correlate my findings.
> 
>  
> 
> 7.  Evidence of active targeting:
>  
> 
> It appears to be targeted in the sense that it is targeting 
> three specific ports as possible back doors to compromised 
> systems.  Also, the attacker is scanning the full range of 
> addresses on this particular subnet.  The scans are not rapid 
> in succession but fairly consistent.
> 
>  
> 
> 8.  Severity:
>  
> 
> severity = (criticality + lethality) - (system 
> countermeasures + network countermeasures)
> 
> Each value is ranked on a scale from 1 (lowest) to 5 (highest).
> 
>  
> 
> Criticality: 2
> 
>  
> 
> I believe that criticality is low based on the fact that we 
> do not run socks or squid proxies on our network.  It is 
> possible that the myDoom virus could be introduced but active 
> virus scanning with updated definitions is in use.
> 
>  
> 
> Lethality: 3
> 
>  
> 
> I do not think that this scan in itself is very lethal but 
> the nature of business on my network a compromise could be 
> very lethal.  A continued monitoring of this type of scan and 
> any other associated IP addresses should be considered.
> 
>  
> 
> System countermeasures: 2
> 
>  
> 
> The systems on this network are patched and updated regularly 
> or as they become available.  The systems administrators do a 
> fair job of ensuring that the systems are secure and up to date.
> 
>  
> 
> Network countermeasures: 3
> 
>  
> 
> I am happy to say that this scan was denied at the border 
> router.  The network currently uses a defense-in-depth 
> approach.  Inside the border router, using extensive ACLs, is 
> monitored by a network IDS.  A firewall is then in place that 
> all traffic to the internal network is routed through.  The 
> internal network is monitored by multiple network IDS on 
> various segments along with Cisco IDS modules in the 
> switches.  Correlation with various agencies allows us to put 
> preventative measures up at the border ahead of time.

You might want to do a network description above since you know the
network.

> 
>  
> 
> 9.  Defensive Recommendations:
>  
> 
> The border router should be configured to block incoming 
> requests for services that are not in use or vulnerable to 
> remote access.  If the scan is coming from a specific host, 
> then that IP address can be blocked at the router.  
> Firewalls, should also be set to block any unused services.  
> Since the scan also includes the port commonly associated 
> with the myDoom virus, a full system scan with updated 
> definitions should be done on all systems to ensure that none 
> of the systems have been compromised. 
> 
>  
> 
> 10.  Multiple choice test question:
>  
> 
> What range of ports does the myDoom virus open up and listen on?

Mydoom.a or .b? 

> 
>  
> 
> a.      4200-4000
> 
> b.      3127-3198
> 
> c.      1024-1029
> 
> d.      135-139
> 
>  
> 
> Answer: b.
> 
> A system that has been compromised by the myDoom virus opens 
> ports 3127-3198, according to CERT 
> http://www.cert.org/incident_notes/IN-2004-> 01.html.
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> ------------------
> 
> [1] LinkLogger
> _______________________________________________
> Intrusions mailing list
> Intrusions at lists.sans.org
> http://www.dshield.org/mailman/listinfo/intrusions
> 



More information about the Intrusions mailing list