        ĳ
                                +-+-+-+-+-+-+-+-+
         ۲|O|u|t|b|r|e|a|k|𰰰
                                +-+-+-+-+-+-+-+-+
                             Issue #4 - Page 5 of 12 
        ĳ   



###########################################
##...network reconnaissance. -dropcode...##
###########################################

"know thy enemy..." -sun tzu, the art of war.

-----------------------------------------------------------------------

:: introduction ::

network reconnaissance involves gathering information dealing with your 
targets network.  though, often a gruling task, the information gleaned
with  the simple techniques i will explain throughout this article will
allow an attacker to build a complete dossier against a target network.

using  simple  recon techniques an attacker can systematically reduce a
network  from  a  mess  of  connected  machines  to a specific range of 
domains, network blocks and ip addresses.

-----------------------------------------------------------------------

:: public database digging ::

there  are  generally three areas of important info that can be gleaned 
from  public  databases  related  to  the  targets  network,  they  are 
registrar, domain and network.

registrar  queries provide the attacker with specific whois / registrar 
servers directly associated with the targets network. this is important
because  these  associated  servers  are where the next queries will be
directed.

in  the  following  example,  i will be performing a registrar query on
psuedo  networks  inc.  from  a  bash shell.  of course, the crsnic.net 
server  could  be  queried  in  other  ways,  the bash shell was only a 
preference.

---
 $ whois "psuedo."@whois.crsnic.net
 
 psuedostuff.com
 psuedosomethin.com
 psuedo.net
 psuedopsuedo.org
--- 

placing the . wildcard at the end of my search string forced the server
to  return all occurances of psuedo in the crsnic.net database.  we can 
now  dig  deeper to determine which domain is the one we want.  i would
guess that psuedo.net is our best chance.

---
  $ whois "psuedo.net"@whois.crsnic.net

  Domain Name: PSUEDO.NET
  Registrar: NETWORK SOLUTIONS, INC.
  Whois Server: whois.networksolutions.com
  Referral URL: www.networksolutions.com
  Name Server: DNS1.PSUEDO.NET
  Name Server: DNS2.PSUEDO.NET
---
  
blamo.  from  that  query we see that whois.networksolutions.com is the 
server we should direct our next queries at. 

the  domain  query  will  provide  us  with information relating to the
registrant,  the  domain  name, admin, when the record was last updated
and  the  primary  and  secondary  dns  servers  (also aquired from the 
first query)

---
  $ whois psuedo.net@whois.networksolutions.com
  
  [whios.networksolutions.com]
  Registrant:

  Psuedo Networks, Inc. (PSUEDO-DOM)
  123 nowhere ave.
  Buttfsck, AZ 12345

  Domain Name: PSUEDO.NET

  Administrative Contact, Technical Contact, Zone Contact:
  Rick, Slick [Network do0d] (SR924)  slickrick@PSUEDO.NET
  710-555-1234 (fax) 710-555-1235
  
  Record last updated on 30-Mar-02.
  Record created on 30-Mar-02.
  Database last updated on 10-Mar-02.

  Domain servers in listed order:
     DNS1.PSUEDO.NET	    10.10.10.1
     DNS2.PSUEDO.NET	    10.10.10.2
---

the word record refers to the information stored in the whois database.
if the record was created years ago and hasn't been updated,  its quite
possible  that  the  information in the record is out of date.  but  if 
the update is recent we've aquired a wealth of information on our mark.

lastly, the network query. american registry of internet numbers [arin]
maintains  actual  network blocks and ownership information in a gorga-
massive database. we will use whois to query the arin database:

---
  $ whois "Psuedo Networks."@whois.arin.net
  [whois.arin.net]
  Psuedo Networks (NETBLK)	10.10.10.0 - 10.50.129.255
---
  
a  tighter  search  can  be made using a netblock as our search string.

---
  $ whois 10.10.10.0@whois.arin.net
  [whois.arin.net]
  Some Big Backbone (NETBLK NA-05BLK)	10.10.0.0 - 10.10.255.255
  Psuedo Networks (NETBLK NA-10-10-10-) 10.10.10.0 - 10.50.129.255
---

basically,  arin.net's  database  has given us a network block owned by 
psuedo  networks,  inc. thereby providing the attacker with a basic map 
of systems to target.

-----------------------------------------------------------------------

:: ping sweeping ::

ping  sweeping  is a very simple, but quite versatile technique used to 
determine  which  ip's  in  a  given  network  block  are actually live 
machines. 

the  basic  concept is to ping a range of ip's, compiling a list of the 
ones  that  respond.  for  instance,  psuedo  networks  own  a  class c 
netblock ranging from 10.10.10.0 to 10.50.129.255. at first glance this
seems  likely to be a long gruling process, and often it is, especially
if  you're  mapping a larger class a type netblock. however, there is a 
simple  technique  to quicken the process. there are a few programs out 
that,  instead  of  pinging  each system subsequently, send out all the 
pings  at  once  and  idle  waiting for the replies. this speeds up the 
process significantly.

generally,  pinging  a  host sends an icmp echo packet (icmp type 0x08) 
and  waits  for an icmp echo_reply packet (icmp type 0x00). this method 
is  sometimes erroneous due to the fact that acd's are often configured 
to  filter  icmp packets. it is possible to use a similar method to see 
if  a  system is alive called the tcp ping. this methed sends a tcp ack 
to  the  system and waits for an rst, showing that the system is infact
alive.

gping/fping/hping are very handy *nix programs capable of ping sweeping
a network block. 

-----------------------------------------------------------------------
:: traceroute/tracert ::

using  traceroute  it  is  possible to find firewalls, packet filtering
devices and  other  access control devices [acd] on the target network.

---
  $ traceroute psuedo.net
  traceroute to psuedo.net (10.10.10.1), 30 hops max, 40 byte packets
  1 box1 (207.124.10.1) 5.133 ms 5.101 ms 5.111 ms
  2 rtr1.bigbackbone.net (10.10.22.10) 40.103 ms 40.210 ms 41.122 ms
  3 rtr2.bigbackbone.net (10.10.22.11) 43.123 ms 43.163 ms 43.211 ms
  4 acd.bigbackbone.net (10.10.11.11) 45.533 ms 45.364 ms 47.164 ms
  5 box.psuedo.net (10.10.10.1) 47.733 ms 47.103 ms 47.603 ms
---

generally,  it  is safe to assume that the last hop before an important
machine  on  the  targets  network  is  some form of acd on their isp's 
network.  this acd can be anything from a physical hardware firewall to
a  simple  packet filtering device or router. in the above example, hop
four is likely an acd.

traceroute  generally  uses udp packets by default allowing the user to 
switch  to  icmp  if they feel if necesary  at  the command line.  (the 
reverse  is  true  for  tracert  users)  often  acd's  will filter icmp 
or udp packets and give you output such as:

---
  $ traceroute psuedo.net
  traceroute to psuedo.net (10.10.10.1), 30 hops max, 40 byte packets
  1  box1 (207.124.10.1) 5.133 ms 5.101 ms 5.111 ms
  2  rtr1.bigbackbone.net (10.10.22.10) 40.103 ms 40.210 ms 41.122 ms
  3  rtr2.bigbackbone.net (10.10.22.11) 43.123 ms 43.163 ms 43.211 ms
  4  acd.bigbackbone.net (10.10.11.11) 45.533 ms 45.364 ms 47.164 ms
  5  *   *   *
  6  *   *   *
---

it  is  possible  that switching the type of packets traceroute/tracert
sends  might bypass this form of acd filtering. also, it is possible to 
use  the  -p  switch to specify a starting udp port in conjunction with 
the  -S  switch to stop port incrementation. generally, traceroute will
start  at  the  port specified with -p and increment +1. with -S switch 
you can specify a port and keep all packets sending there. for instance
udp  port  53  handles  dns queries. since most acd's allow inbound dns 
queries,  its  very  likely that if you point your traceroute to 53, it
will bypass the acd's filtering and allow you to see beyond the acd.

-----------------------------------------------------------------------

:: port scanning ::

once you have a list of operational systems on your targets network you
can  begin  looking  for vulnerable services on each individual system.
this  can  be  accomplished  by connecting to every tcp/udp port on the 
victims machine to determine which ports are set in listening state.

if  a  port is listening, there's a good chance that there is a service 
daemon  running on that machine handling connections to that port.  and 
if there's a daemon running, there's a chance that it's vulnerable.

for  instance, http daemons, or webservers generally run on port 80. if
port   80  is  listening,  its  quite likely that the target machine is 
running a webserver.

-tcp full connection scan:
 -------------------------
 the  most  common  type  of port scan is the tcp full connection scan. 
 this  type  of scan completes a threeway handshake, syn, syn/ack, ack. 
 this method is easily detectable  but, with this method it is possible 
 to grab the  daemons  banner which often includes the name and version 
 of the running service.

-tcp syn scan:
 -------------
 the  tcp  syn scan is a little more stealthy because a full connection
 is  never made. the downside is that with a syn scan banners cannot be
 retrieved.  however, an attacker can make an educated guess as to what
 service  is  running  on the port because all services have a default. 
 (httpd:80, ftpd:21, telnetd:23, smtpd:25, etc)

-tcp ack scan:
 -------------
 this method can help in determining what types of packets are filtered
 by  an acd. the tcp ack bit is set before the packet is sent to see if 
 the acd filters packets without this bit set. 

-tcp fin scan:
 -------------
 fin  packets are sent to the target system on every port subsequently.
 all closed ports should reply with rst's according to the standards of
 the tcp protocol.

-tcp xmas scan:
 --------------
 an advanced version of the fin scan, the xmas method sends fin, urg 
 and push packets also forcing rst's from all closed ports.

-tcp null scan:
 --------------
 a  tcp null scan sends packets to the target machine with no bits set.
 this forces all closed ports to respond with an rst.
  
-udp scan:
 ---------
 the  basic  principal  of  a  udp  scan  is  that  when  no  icmp port 
 unreachable msg is recieved, the port must be listening. 

-----------------------------------------------------------------------

:: outro ::

well, thats about it for network recon. any questions or comments can
be emailed to me at uberego@hotmail.com ... 

respect to:  gr3p,  rambo,  adeamis, smurf, fork, smiley, antimatt3r, 
             gambiit, ocean, ech0. droptone:  dood,  it looks so much 
             better on me :P, abused: xoxoxxx, heather:  can't we all 
	     jus' get along? kleptic: don't give up on outbreak, dood
             people need you. :) honeypot: i lub j0o.
             ... anyone I'm forgetting, meh. :)

EOF.

-----------------------------------------------------------------------
	     