Site Tools

NOTE : Some link might not work, but search based on the name and site.

Vulnerabilities due to improperly configured operating system software

Vulnerabilities due to failure to apply patches to known vulnerabilities

Failure to comply with password policy and improper access control settings

Existence of malicious software (Trojans, worms, etc.) or evidence of use

Existence of vulnerable or easily exploited services or processes

Vulnerabilities due to improperly configured applications

1. NSA IAM
2. CESG CHECK

1. PCI Secuity
2. Mastercard Information
3. Visa Information

1. ISECOM’s Open Source Security
2. Council of Registered Ethical Security Testers
3. Tiger Scheme
4. EC-Counsil
5. Open Web Application Security Project

1. Packet Storm
2. Milw0rm
3. FrSIRT
4. Security Focus
5. CERT vulnerability notes
6. MITRE Corporation CVE
7. ISS X-Force

1. eEye Preview
2. 3Com TippingPoint DVLabs
3. VeriSign iDefense Security Intelligence Services

1. BiDiBLAH
2. The SensePost Black Hat USA 2005 presentation slides

1. nmap
2. Nessus
3. NSAT
4. Foundstone SuperScan

1. Core IMPACT
2. ISS Internet Scanner
3. Cisco Secure Scanner
4. eEye Retina
5. QualysGuard
6. Matta Colossus

1. The Metasploit Framework

1. Core Security
2. Immunity Inc.
3. GLEG VulnDisco
4. Ageniss Ultimate 0day Exploits Pack

1. Paros
2. WebScarab
3. Burp suite

1. Wapiti
2. Nikto

1. Watchfire AppScan
2. SPI Dynamics WebInspect
3. Cenzic Hailstorm

1. enum
2. epdump
3. “nbtstat” Available with Microsoft OS's
4. usrstat

1. SMBCrack
2. WMICracker
3. SMB Auditing tools

1. nslookup
2. host and dig
3. ghba (available at tools links it is source)

1. We can cross-reference AS11278 at http://fixedorbit.com/search.htm to reveal the IP blocks associated with the AS number.
2. Many BGP looking glass sites and route servers can be queried to reveal this information. Route servers are maintained by ISPs and can be connected to using Telnet to issue specific BGP queries. A list of looking glass sites and route servers is maintained by NANOG at http://www.nanog.org/lookingglass.html

1. N-Stealth
2. nikto
3. cgichk

 +"ucia.go" +tel +fax

allintitle: "index of /" site:.redhat.com

** Another site for effective search Netcraft

 * whois cs-security-mnt
 * whois "@citicorp.com" @whois.arin.net

• Forward DNS querying transfer using nslookup

  #nslookup
  >set querytype=any
  >cia.gov
  >server auth100.ns.uu.net             #zone transfer using nslookup.
  >ls -d ucia.gov
 

• Using dig to perform a DNS zone transfer

  dig @relay2.ucia.gov ucia.gov axfr
 

• PTR record enumeration through DNS zone transfer

  dig @relay2.ucia.gov 129.81.198.in-addr.arpa axfr
 

• Using a forward DNS lookup to enumerate MX records

  $ nslookup
  > set querytype=mx
  > bankofengland.co.uk
 

• Windows tool that support dictionary-based hostname grinding

TXDNS

 txdns -f mail-dict.txt bankofengland.co.uk
 

• GHBA

 $ghba 198.81.129.0
 

• Wikto
• HTTrack
• BlackWidow
• GNU Wget

Wikipedia Entry for Crowler

• SpiderFoot
• BiDiBLAH

Reading/Understanding Header of Returned Mail.

  The original message was received at Fri, 1 Mar 2002 07:42:48 -0500
  from ain-relay2.net.ucia.gov [192.168.64.3]
  ----- The following addresses had permanent fatal errors -----
  <blahblah@ucia.gov>
  ----- Transcript of session follows -----
  ... while talking to mailhub.ucia.gov:
  >>> RCPT To:<blahblah@ucia.gov>
  <<< 550 5.1.1 <blahblah@ucia.gov>... User unknown
  550 <blahblah@ucia.gov>... User unknown
  ----- Original message follows -----
  Return-Path: <hacker@hotmail.com>
  Received: from relay2.net.ucia.gov
  by puff.ucia.gov (8.8.8+Sun/ucia internal v1.35)
  with SMTP id HAA29202; Fri, 1 Mar 2002 07:42:48 -0500 (EST)
  Received: by relay2.net.ucia.gov; Fri, 1 Mar 2002 07:39:18
  Received: from 212.84.12.106 by relay2.net.ucia.gov via smap (4.1)
  id xma026449; Fri, 1 Mar 02 07:38:55 -0500
 

Reading above header in English

  In particular, the following data in this transcript is useful:
  • The Internet-based relay2.ucia.gov gateway has an internal IP address of
    192.168.64.3 and an internal DNS name of relay2.net.ucia.gov.
  • relay2.ucia.gov is running TIS Gauntlet 4.1 (smap 4.1, a component of TIS
    Gauntlet, is mentioned in the via field).
  • puff.ucia.gov is an internal SMTP mail relay system running Sun Sendmail
    8.8.8.
  • mailhub.ucia.gov is another internal mail relay running Sendmail (this can be
    seen from analyzing the SMTP server responses to the RCPT TO: command).

From a network scanning perspective, the following types of ICMP messages are useful:

1. Type 8 (echo request)
2. Type 13 (timestamp request)
3. Type 15 (information request)
4. Type 17 (subnet address mask request)

• SING - Send ICMP Nasty Garbage (is a command-line utility that sends customizable ICMP probes.)

SING Source

 $ sing -echo 192.168.0.255
 $ sing -tstamp 192.168.0.50
 $ sing -mask 192.168.0.25
 

• Nmap - can perform ICMP ping sweep scans of target IP blocks easily

NMAP Source

 $ nmap -sP -PI 192.168.0.0/24 (Performing a ping sweep with Nmap)
 

• ICMPScan - ICMPScan is a bulk scanner that sends type 8, 13, 15, and 17 ICMP messages

ICMPScan Source

 You can get how to use by simply running application
 $ icmpscan –c -t 500 -r 1 192.168.1.0/24
 

Enumerating subnet network and broadcast addresses with Nmap

nmap -sP 154.14.224.0/26

Useful details about subnet network and broadcast addresses and
CIDR slash notation can be found at http://en.wikipedia.org/wiki/
Classless_Inter-Domain_Routing.

Accessible TCP ports can be identified by port scanning target IP addresses. The
following nine different types of TCP port scanning are used in the wild by both
attackers and security consultants:

Standard scanning methods
Vanilla connect( ) scanning
Half-open SYN flag scanning
 
Stealth TCP scanning methods
Inverse TCP flag scanning
ACK flag probe scanning
TCP fragmentation scanning
 
Third-party and spoofed TCP scanning methods
FTP bounce scanning
Proxy bounce scanning
Sniffer-based spoofed scanning
IP ID header scanning

Using Nmap to perform IP ID header scanning

nmap -P0 -sI 192.168.0.155 192.168.0.50

Nice tools From Fryxar

Probe packets can be fragmented easily with fragroute to fragment all probe packets
flowing from your host or network or with a port scanner that supports simple
fragmentation, such as Nmap. Many IDS sensors can’t process large volumes of fragmented
packets because doing so creates a large overhead in terms of memory and
CPU consumption at the network sensor level.

Dug Song’s fragtest utility can determine exactly which types of fragmented
ICMP messages are processed and responded to by the remote host. ICMP
echo request messages are used by fragtest for simplicity and allow for easy analysis;
the downside is that the tool can’t assess hosts that don’t respond to ICMP
messages.
After undertaking ICMP probing exercises (such as ping sweeping and hands-on use
of the sing utility) to ensure that ICMP messages are processed and responded to by
the remote host, fragtest can perform three particularly useful tests:

• Send an ICMP echo request message in 8-byte fragments (using the frag option)
• Send an ICMP echo request message in 8-byte fragments, along with a 16-byte overlapping fragment, favoring newer data in reassembly (using the frag-new option)
• Send an ICMP echo request message in 8-byte fragments, along with a 16-byte

overlapping fragment, favoring older data in reassembly (using the frag-old option) Here is an example that uses fragtest to assess responses to fragmented ICMP echo
request messages with the frag, frag-new, and frag-old options:

$ fragtest frag frag-new frag-old www.bbc.co.uk
frag: 467.695 ms
frag-new: 516.327 ms
frag-old: 471.260 ms

The fragroute utility intercepts, modifies, and rewrites egress traffic destined for a
specific host, according to a predefined rule set. When built and installed, version 1.2
comprises the following binary and configuration files:

/usr/local/sbin/fragtest
/usr/local/sbin/fragroute
/usr/local/etc/fragroute.conf

The fragroute.conf file defines the way fragroute fragments, delays, drops, duplicates,
segments, interleaves, and generally mangles outbound IP traffic.
Using the default configuration file, fragroute can be run from the command line in
the following manner:

$ cat /usr/local/etc/fragroute.conf
tcp_seg 1 new
ip_frag 24
ip_chaff dup
order random
print
$ fragroute
Usage: fragroute [-f file] dst
$ fragroute 192.168.102.251
fragroute: tcp_seg -> ip_frag -> ip_chaff -> order -> print

Egress traffic processed by fragroute is displayed in tcpdump format if the print
option is used in the configuration file. When running fragroute in its default configuration,
TCP data is broken down into 1-byte segments and IP data into 24-byte
segments, along with IP chaffing and random reordering of the outbound packets.
fragroute.conf. The fragroute man page covers all the variables that can be set within
the configuration file. The type of IP fragmentation and reordering used by fragtest
when using the frag-new option can be applied to all outbound IP traffic destined for
a specific host by defining the following variables in the fragroute.conf file:

ip_frag 8 old
order random
print

TCP data can be segmented into 4-byte, forward-overlapping chunks (favoring
newer data), interleaved with random chaff segments bearing older timestamp
options (for PAWS elimination), and reordered randomly using these fragroute.conf
variables:

tcp_seg 4 new
tcp_chaff paws
order random
print

I recommend testing the variables used by fragroute in a controlled environment
before live networks and systems are tested. This ensures that you see decent results
when passing probes through fragroute and allows you to check for adverse reactions
to fragmented traffic being processed. Applications and hardware appliances
alike have been known to crash and hang from processing heavily fragmented and mangled data!

Nice tools from Dugsongs

Using Nmap to perform a fragmented SYN scan

$ nmap -sS -f 192.168.102.251

Using Nmap to specify decoy addresses

$ nmap -sS -P0 -D 62.232.12.8,ME,65.213.217.241 192.168.102.251

tools that can assess and exploit source routing vulnerabilities found in
remote networks:

• LSRScan lsrscan
• LSRTunnel lsrtunnel

LSRScan. The LSRScan tool crafts probe packets with specific source routing options
to determine exactly how remote hosts deal with source-routed packets. The tool
checks for the following two behaviors:

• Whether the target host reverses the source route when sending packets back
• Whether the target host can forward source-routed packets to an internal host, by setting the offset pointer to be greater than the number of hops defined in the loose hop list

The basic usage of the tool is as follows:

$ lsrscan
usage: lsrscan [-p dstport] [-s srcport] [-S ip]
[-t (to|through|both)] [-b host<:host ...>]
[-a host<:host ...>] <hosts>

LSRTunnel. LSRTunnel spoofs connections using source-routed packets. For the tool
to work, the target host must reverse the source route (otherwise the user will not see
the responses and be able to spoof a full TCP connection). LSRTunnel requires a
spare IP address on the local subnet to use as a proxy for the remote host.
Running LSRTunnel with no options shows the usage syntax:

$ lsrtunnel
usage: lsrtunnel -i <proxy IP> -t <target IP> -f <spoofed IP>

information regarding circumvention of Firewall-1 in certain
configurations, consult the excellent presentation from Black Hat Briefings 2000 by
Thomas Lopatic et al. titled “A Stateful Inspection of Firewall-1” available as a Real
Media video stream and PowerPoint presentation from Link

Tools such as Nmap, Hping2, and Firewalk perform low-level IP assessment.

Insight into the following areas of a network can be gleaned through low-level IP assessment:

• Uptime of target hosts (by analyzing the TCP timestamp option)
• TCP services that are permitted through the firewall (by analyzing responses to TCP and ICMP probes)
• TCP sequence and IP ID incrementation (by running predictability tests)
• The operating system of the target host (using IP fingerprinting)

The TCP timestamp option is defined in RFC 1323.

A TCP probe always results in one of four responses. These responses potentially
allow an analyst to identify where a connection was accepted, or why and where it
was rejected, dropped, or lost:

• TCP SYN/ACK

If a SYN/ACK packet is received, the port is considered open.

• TCP RST/ACK

If an RST/ACK packet is received, the probe packet was rejected by either the
target host or an upstream security device (e.g., a firewall with a reject rule in its policy).

• ICMP type 3 code 13

If an ICMP type 3 code 13 message is received, the host (or a device such as a
firewall) has administratively prohibited the connection according to an Access Control List (ACL) rule.

• Nothing

If no packet is received, an intermediary security device silently dropped it.

dumping traffic with pcap_filter

tcpdump -i eth2 -s 0 -w /tmp/mar_2017.pcap host 192.168.1.86

Reading pcap output file

tcpdump -qns 0 -X -r /tmp/mar_2017.pcap