Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Nessus-Users
[Top] [All Lists]

Re: NASL Script for plugin ID 10330

Subject: Re: NASL Script for plugin ID 10330
Date: Fri, 21 Sep 2007 08:36:37 -0400

Message: 5
Date: Wed, 19 Sep 2007 13:40:41 -0400
From: "George A. Theall" <theall@tenablesecurity.com>
Subject: Re: Nessus Digest, Vol 47, Issue 13
To: nessus@list.nessus.org 
Message-ID: <46F15F19.4090405@tenablesecurity.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 09/19/07 13:12, Joel Elwell wrote:

I noted that the plugin "find_service.nasl" in version 3.0.3, indicates it's 
meant to replace the 
"find_service.nes". Which is actually running in my case? One or both?

find_service.nasl will replace the C-language plugin starting in Nessus 3.2.

Thanks for the clarification.

For additional background info: The DoS target is a presentation layer 
"service" providing SQL database
info from the back end to the application running in a browser session. Runs 
on Windows Server 2003 and IIS.

When you're running your scans and seeing CPU usage spike, you're 
enabling just #10330 for service detection, right?

That is correct. The only plugin enabled is #10330

Is the target remote?

Yes, the target is remote. 

What services are listening remotely? Which processes are using most of 
the CPU when the DoS occurs?

I'll have to run another scan, and watch all the services as the scan leads up 
to the DoS,
 however the proprietary app (can't name it, sorry) is what pegs the CPU at 99%.
Here's the services/ports based on NMAP scan.

80/tcp   open  http
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
427/tcp  open  svrloc
443/tcp  open  https
445/tcp  open  microsoft-ds
1029/tcp open  ms-lsa
1031/tcp open  iad2
2105/tcp open  eklogin
3389/tcp open  ms-term-serv

123/udp  open|filtered ntp
137/udp  open|filtered netbios-ns
138/udp  open|filtered netbios-dgm
161/udp  open|filtered snmp
427/udp  open|filtered svrloc
445/udp  open|filtered microsoft-ds
500/udp  open|filtered isakmp
1025/udp open|filtered blackjack
1028/udp open|filtered ms-lsa
1030/udp open|filtered iad1
4500/udp open|filtered sae-urn





George
-- 
theall@tenablesecurity.com 



_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus

<Prev in Thread] Current Thread [Next in Thread>