Whitepapers - www.technicalinfo.net


  Passive Information Gathering (Part 1)
The Analysis of Leaked Network Security Information


Most organisations are familiar with Penetration Testing (often abbreviated to, “pentesting”) and other ethical hacking techniques as a means to understanding the current security status of their information system assets. Consequently, much of the focus of research, discussion, and practice, has traditionally been placed upon active probing and exploitation of security vulnerabilities. Since this type of active probing involves interacting with the target, it is often easily identifiable with the analysis of firewall and intrusion detection/prevention device (IDS or IPS) log files.

However, too many organisations fail to identify the potential threats from information unintentionally leaked, freely available over the Internet, and not normally identifiable from standard log file analysis. Most critically, an attacker can passively gather this information without ever coming into direct contact with the organisations servers – thus being essentially undetectable.

Very little information has been publicly discussed about arguably one of the least understood, and most significant stages of penetration testing – the process of Passive Information Gathering. This technical paper reviews the processes and techniques related to the discovery of leaked information. It also includes details on both the significance of the leaked information, and steps organisations should take to halt or limit their exposure to this threat.

Information Leakage

Like it or not, every Internet-connected system unintentionally leaks internal information about their organisation which could be used to formulate a targeted attack. Depending upon the source of this leakage, the information may relate to the components used within the organisation’s physical asset infrastructure, the management processes utilised, or the operational “personnel” hierarchy.

The significance of this leaked information may not be entirely obvious to some organisations. In the majority of cases, much of the leaked information relates to the topology of the organisations network and the types of services within. This enables an attacker to provisionally map out the network for coordinating more sophisticated attacks at a later date.

In addition, the harvesting of information relating to specific employees (in particular administrative staff) can be actively employed in social engineering attacks – perhaps through deception, bribery or blackmail. Past examples of this include staff blackmailed into providing confidential information due to racial and sexist remarks posted to public newsgroups via their corporate Internet account.

An important aspect of this information leakage is that most of it is publicly available using the Internet, and probably contained on systems unrelated to the organisation. Consequently, access to the information is independent of the organisations resources and thus can effectively be accessed “anonymously” by anyone. The processes for discovering this leaked information tends to be very simple and a multitude of tools are readily accessible to make it as even easier. In fact, many of the tools are either already built in to the most popular operating systems, or can be freely accessed from various websites.

The techniques used to uncover this leaked information are commonly referred to as “Passive Information Gathering” – and they form a vital (and often overlooked) role in any quality penetration test or security assessment.

Definition of “Passive”

Before delving into the techniques of Passive Information Gathering, it is important to understand what is meant by the term “passive”.  A dictionary provides two relevant definitions:

pas·sive (adj.)

  1. Receiving or subjected to an action without responding or initiating an action in return.
  2. Accepting or submitting without objection or resistance.

From an ethical hacking perspective, the focus is upon identifying information about the organisation under investigation, without the organisation being aware that the information has been accessed.

In the context of this technical whitepaper, “passive” refers to techniques that either do not connect to a system owned or managed by the organisation (thus they would be unaware of any such access), access to information from the organisations systems which is commonly available and would not normally ever be associated as a precursor to future attacks, or via the increasingly numerous online security analysis websites.

This includes non-intrusive techniques such as searching generic Internet resources like www.google.com for information relating to the organisation, and encompasses analysis of data returned during normal interaction with the organisation – for example the banners and other system messages returned when connection to the web or mail server. However, it does not include intrusive network enumeration phases such as port-scanning.

Passive Information Gathering Techniques

There are a number of techniques and processes available when carrying out a Passive Information Gathering exercise. This technical whitepaper will detail the most relevant techniques and endeavour to elaborate both the thought processes necessary to identify the leaked information, and to evaluate the relative security risks associated with the leakage.

A lot of important information can be passively harvested and subsequently used in a direct attack or to reinforce other attacks targeted at an organisation. Depending upon the source, information such as current service patching levels, internal network architecture layout and account details can be easily obtained. Just as importantly, with a little insight as to where this information is obtained and the level of detail of information, an organisation can often rectify this information leakage simply and quickly.

The most critical phases or investigation processes revolve around the accessibility of various online resources such as:

  • Internet Service Registration – The global registration and maintenance of IP address information
  • Domain Name System – Local and global registration and maintenance of host naming
  • Search Engines – The specialist retrieval of distributed material relating to an organisation or their employees
  • Email Systems – The information contained within each email delivery process
  • Naming Conventions – The way an organisation encodes or categorises the services their online hosts provide
  • Website Analysis – The information intentionally made public, that may pose a risk to security

Internet Service Registration

In order to access networked resources over the Internet, every accessible host must have a unique and routable IP address. Whilst there is slow take-up of IPv6, IPv4 is still the de-facto standard and will be considered in this document. This IP address takes the form of xxx.xxx.xxx.xxx, where “xxx” may be some value between 0 and 255. In order to simplify host addressing, and to make hosts more memorable, services exist that associate IP addresses to a unique domain name (for instance www.abcexample.com).

Both the registration of IP addresses and domain names are coordinated at an international level. In order to administer these IP addresses (or address ranges) and domain names, organisations must supply administrative details including physical billing addresses and technical contact information. By necessity, this information is publicly available and may be requested by anyone over the Internet. Consequently, these international databases may are queried and form the first stages of the Passive Information Gathering exercise.

Dividing the responsibility between them, there are exist four Regional Internet Registries (RIR). These RIRs provide allocation and registration services and support the operation of the Internet globally.  Responsibilities include the allocation of Internet (IP) address space, autonomous system numbers (ASNs) and the management of reverse domain name space.  The four RIRs are:

  • APNIC (Asia-Pacific Network Information Center)
  • ARIN (American Registry for Internet Numbers)
  • LACNIC (Latin American and Caribbean Internet Addresses Registry)
  • RIPE NCC  (Réseaux IP Européens Network Coordination Centre)


There are two primary WHOIS resources – Network service-based and Name service-based. As the names suggest, one focuses upon the registration and management of individual/blocks of IP addresses (note that a block or range of IP addresses is commonly referred to as a “netblock”), while the other focuses upon the registration and management of domain names.

The core RIR WHOIS services provide a mechanism for finding contact and registration information for resources registered with the individual registries. These databases contain IP addresses, autonomous system (AS) numbers, organisations or customers that are associated with these resources, and related Points of Contact (POC).

The RIR WHOIS services will typically not locate any domain-related information or any information relating to military networks. For domain name lookups, various online resources exist – however www.internic.net/whois.html and www.uwhois.com are recommended for non-military, and whois.nic.mil for military network information.

Network Service-Based WHOIS

Network service-based WHOIS data provides details of network management data. The data is commonly used by network and security personnel to reach, or otherwise contact, an organisations technical staff should a problem arise. This registration and administration data include information such as the contact provider of the network numbers, and in some situations the company leasing the address space.

Worked Example – One

Let us consider the investigation of the example company ABC Example Ltd., and start with the primary web site www.example.com. A quick lookup of the host name (via nslookup or even ping) reveals the unique IP address to be 213.48.xx.45. In this instance, we note that the IP address is part of a Class A address range (i.e. 213.xxx.xxx.xxx) normally associated with Western Europe.

As this is a European IP address range, we should direct any network service WHOIS queries to RIPE NCC, e.g. whois -h whois.ripe.net <query string>

1. % This is the RIPE Whois server.
2. % The objects are in RPSL format.
3. %
4. % Rights restricted by copyright.
5. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html
6. inetnum: 213.48.xx.0 - 213.48.xx.63
7. netname: ABC-EXAMPLE
8. descr: INTERNET
9. country: GB
10. admin-c: TWIP1-RIPE
11. tech-c: TWIP2-RIPE
12. status: ASSIGNED PA
13. mnt-by: AS546x-MNT
14. remarks: report abuse to abuse@blueyonder.co.uk
15. remarks: All reports via other channels will be ignored.
16. changed: ripe-admin@blueyonder.co.uk 20020709
17. source: RIPE
18. route:
19. descr: Telewest Broadband
20. descr: UK Broadband ISP
21. origin: AS5462x
22. notify: ripe@telewest.net
23. mnt-by: AS546x-MNT
24. remarks: report abuse to abuse@blueyonder.co.uk
25. remarks: All reports via other channels will be ignored.
26. changed: ripe-admin@blueyonder.co.uk 20020709
27. source: RIPE
28. role: Telewest Broadband IP Network Services
29. address: Genesis Business Park
30. address: Albert Drive
31. address: Woking
32. address: Surrey UK
33. address: GU21 5RW
34. e-mail: ripe@telewest.net
35. admin-c: JH1542x-RIPE
36. tech-c: AH1530x-RIPE
37. tech-c: DR1307x-RIPE
38. tech-c: DS1550x-RIPE
39. tech-c: KJ2418-RIPE
40. tech-c: MG645-RIPE
41. tech-c: SA3620-RIPE
42. tech-c: SB5110-RIPE
43. tech-c: SL3595-RIPE
44. nic-hdl: TWIP1-RIPE
45. notify: ripe@telewest.net
46. mnt-by: AS546x-MNT
47. changed: ripe@telewest.net 20030820
48. source: RIPE
49. role: Telewest Broadband Business Internet
50. address: Genesis Business Park
51. address: Albert Drive
52. address: Woking
53. address: Surrey UK
54. address: GU21 5RW
55. e-mail: ripe@telewest.net
56. admin-c: JH1542x-RIPE
57. tech-c: LM5500x-RIPE
58. tech-c: MB3445x-RIPE
59. nic-hdl: TWIP2xx-RIPE
60. notify: ripe@telewest.net
61. mnt-by: as546x-mnt
62. changed: jim.haffey@telewest.net 20030103
63. source: RIPE


  • Firstly, we note that the Class B IP address range (CIDR is managed by Telewest Broadband – [lines 18 & 19]

  • The Telewest Broadband ISP is UK based and appears to have two business roles; “Telewest Broadband IP Network Service” and “Telewest Broadband Business Internet” – [lines 19-20, 28 and 49]

  • The ISP’s real postal address details have been supplied – [details contained on lines 29-33 and 50-54]

  • The web servers IP address (213.48.xx.45) is just one of 64 that have been allocated to the identifier “ABC-EXAMPLE” – [lines 6 & 7]

  • The registrations for “ABC-EXAMPLE” and “Telewest Broadband” were last changed by “ripe-admin@blueyonder.co.uk” on the same date – [lines 16 & 26]

  • The same MNTNER is responsible for all records (AS546x-MNT) – [lines 13, 23, 46 & 61]

From these observations we can conclude that ABC Example Ltd. has an IP address pool of 64 IP addresses (CIDR that is allocated and managed by Telewest Broadband. Investigation of Telewest Broadband suggests that ABC Example Ltd.subscribes to their South-East England based business broadband offering, and must therefore host their web-site locally.

We also identified that the same maintainer (AS546x-MNT) is responsible for both Telewest Broadband and ABC Example’s netblock registrations. By carrying out an appropriate WHOIS query on the maintainer (querying a MNTNER record), we get the following response from whois.ripe.net:

1. % This is the RIPE Whois server.
2. % The objects are in RPSL format.
3. %
4. % Rights restricted by copyright.
5. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html
6. mntner: AS546x-MNT
7. descr:     Telewest Broadband;
8. descr: UK Broadband ISP
9. descr: report to abuse@blueyonder.co.uk
10. descr: All reports via other channels will be ignored
11. admin-c: JH1542x-RIPE
12. tech-c: MG645xx-RIPE
13. tech-c: SB511xx-RIPE
14. upd-to:   ripe@telewest.net
15. auth: MD5-PW $1$p1Pjw.8d$yDpgtNz2KPpVoSArZaMsC/
16. mnt-by: AS546x-MNT
17. mnt-nfy: ripe@telewest.net
18. referral-by: RIPE-DBM-MNT
19. changed: xxx.haffey@telewest.net 20020613
20. source: RIPE
21. person: XXX Haffey
22. address: Telewest Broadband
23. address: Genesis Business Park
24. address: Albert Drive
25. address: Woking
26. address: UK
27. phone: +44 (0)1483 xx2542
28. e-mail: xxx.haffey@telewest.net
29. notify: xxx.haffey@telewest.net
30. nic-hdl: JH1542x-RIPE
31. changed: xxx.haffey@telewest.net 20020709
32. source: RIPE
33. person: XXX Brocklebank
34. address: Telewest
35. address: Genesis Business Park
36. address: Woking
37. address: Surrey
38. phone: +44 1483 750 900
39. e-mail: xxx@cableinet.net
40. nic-hdl: SB511x-RIPE
41. notify: xxx@cableinet.co.uk
42. changed: xxx@cableinet.net 19990908
43. source: RIPE
44. person: XXX Garrett
45. address: Telewest Communications (Cable Internet)
46. address: Genesis Busines Park
47. address: Woking, Surrey
48. address: GU21 5RW
49. phone: +44 1483 xx6796
50. fax-no: +44 1483 xx1 810
51. e-mail: xxx@cableinet.net
52. nic-hdl: MG64x-RIPE
53. changed: xxx@cableinet.net 20010426
54. source: RIPE


  • Firstly, we note that there are three individuals that are nominated maintainers within the RIPE database for the handle AS5462-MNT. These include “XXX Haffey”, “XXX Brocklebank” and “XXX Garrett” – [lines 21, 33 & 44]
  • We note that various email addresses for these individuals have been supplied belonging to the domains telewest.net, cableinet.co.uk and cableinet.net – [lines 19, 28, 29, 31, 39, 41, 42, 51 & 53]
  • It appears that real, and possibly direct, phone numbers have been supplied for these individuals – [lines 27, 38, 49 & 50]
  • In order to change any entries within the RIPE database, any communications from these individuals must include a password. This password validation is referenced on [line 15] and presented in a MD5 hashed format.  

From a security perspective, a lot of unnecessary information has been leaked by the ISP. The inclusion of real names – combined with email addresses and contact phone numbers – may all be used with great effect in social engineering attacks. Wherever possible, generic role-based names and contact email addresses should be used. In addition, security best practices would recommend that a non-office postal address, and single “reception” phone number be used.  

It is also important to note that, should anyone wish to impersonate one of the authorised netblock maintainers, they would need to supply a password. In this example, the use of an MD5 hash is a strong security choice. The following section briefly covers the significance of this maintenance authentication process.  

NETBLOCK Registration Maintenance

Netblock registration maintenance is normally carried out in a secure and controlled manner. Authorised maintainers are required to authenticate themselves before changes can be made. Authorisation is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.  

Different portions of the RIR databases require different levels of protection. Some applications require authentication based on strong encryption. In other cases strong encryption may not be necessary or may not be legally available. For this reason, multiple authentication methods are supported by the servers.  

The MNTNER objects serve as a container to hold the authentication filters. A reference to a maintainer within another object defines authorisation to perform operations on the object or on a set of related objects. Such reference is provided by means of the "mnt-by:", "mnt-lower:", "mnt-routes:" and "mbrs-by-ref:" attributes.  

The maintainer contains one or more "auth:" attributes. Each "auth:" attribute begins with a keyword identifying the authentication method followed by the authentication information needed to enforce that method.  

When submitting an update that requires authorisation from a MNTNER, authentication information valid for that MNTNER must be supplied. Different methods require different authentication information, as shown below.




No authorisation checks are performed.


This is a very weak authentication check and is discouraged.  The authentication information is a regular expression over ASCII characters.  The maintainer is authenticated if the "From:" field in RFC 822 mail headers are matched by this regular expression. Since mail header forgery is quite easy, this is a very weak form of authentication.

(MAIL-FROM authentication scheme is not valid in the RIPE Database since 11 July 2002.)


This is a relatively weak form of authentication.  The authentication information is a fixed encrypted password in UNIX crypt format.  The maintainer is authenticated if the transaction contains the clear text password of the maintainer.  Since the password is in clear text in transactions, it can be captured by sniffing.  Since the encrypted form of the password is exposed, it is subject to password guessing attacks.  Authentication information is supplied using a "password:" pseudo-attribute. The value of this attribute is a clear-text password. It can appear anywhere in the body of the message, but not within mail headers. Line continuation is not allowed for this attribute.


This scheme is based on the MD5 hash algorithm and provides stronger authentication than CRYP-PW. The authentication information stored in the database is a pass phrase encrypted using md5-crypt algorithm, which is a concatenation of the "$1$" string, the salt, and the 128-bit hash output. Because it uses 8-character salt and an almost unlimited pass phrase, this scheme is more stable against dictionary attacks. However, since the encrypted form is exposed it cannot be considered as a strong form of authentication. Authentication information is supplied using a "password:" pseudo-attribute. The value of this attribute is a clear-text pass phrase. It can appear anywhere in the body of the message, but not within mail headers. Line continuation is not allowed for this attribute, the attribute and the pass phrase should fit on one line. If the key gets split across multiple lines this will be treated as a syntax error.


Strong form of authentication. The authentication information is a signature identity pointing to a public key certificate, which is stored in a separate object. The maintainer is authenticated if the transaction is signed by the corresponding private key. The RIPE NCC does not guarantee that a key belongs to any specific entity; it is not a certificate authority. Anyone can supply any public keys with any ownership information to the database and these keys can be used to protect other objects by checking that the update comes from someone who knows the corresponding secret key.

Following is an example from a poorly secured MNTNER object. In this instance the maintainer has chosen to implement the less secure CRYPT encoding method to protect their administrative password, and also selected a very short password length (see line 7 below).

2. descr: ABC Example Maintainer Object
3. admin-c: DC496x-RIPE
4. tech-c: DC496x-RIPE
5. upd-to: david@example.net.uk
6. mnt-nfy: david@example.net.uk
7. auth: CRYPT-PW haNlLfDHxARrM
8. notify: david@example.net.uk
10. referral-by: RIPE-DBM-MNT
11. changed: hostmaster@ripe.net 20010706
12. source: RIPE

It is important to note that CRYPT encoded passwords can be brute-forced. Thus organisations should be wary of recycling this type of disclosed password on other systems. In the past, organisations have been caught out when using the same password for managing domain registration details and also for accessing the management interface on their border routers.

Name Service-Based WHOIS

Name service-based WHOIS data provides a number of details about a domain. These details include the registrant of the domain, the street address the domain is registered to, and a contact number for the registrant. This data is supplied to facilitate the communication between domain owners in the event of a problem. This is the ideal method of handling problems that arise, although these days the trend seems to be whining to the upstream provider about a problem first (which is extremely bad netiquette).
Domain registration details tend to be more fragmented than Network service-based registration. Consequently there are many more authoritative systems managing domain names. The root domain servers (i.e. those associated with .com, .net, .org, .mil, .uk, .au, etc.) will often refer to other more authoritative WHOIS servers – which should be queried for full registration details. However, many online WHOIS services and downloadable tools will automatically locate and query the authoritative service. One such example is Network Solutions.

Worked Example – Two

Let us continue the investigation of ABC Example Ltd. Utilising a name service-based WHOIS query facility hosted by the main authority on .com name registrations (www.internic.net/whois.html), we query the domain “abcexample.com” and receive the following response:

1. Domain names in the .com and .net domains can now be registered
2. with many different competing registrars. Go to http://www.internic.net
3. for detailed information.
4. Domain Name: ABCEXAMPLE.COM
6. Whois Server: whois.melbourneit.com
7. Referral URL: http://www.melbourneit.com
8. Name Server: NS0.BYWORKWISE.COM
9. Name Server: NS1.BYWORKWISE.COM
10. Status: ACTIVE
11. Updated Date: 22-sep-2003
12. Creation Date: 26-oct-2001
13. Expiration Date: 26-oct-2005
14. >>> Last update of whois database: Fri, 7 Nov 2003 06:26:27 EST <<<


  • The domain “abcexample.com” has been registered with an entity called “Melbourne IT, Ltd” – [line 5]
  • Melbourne IT maintains their own authoritative WHOIS service for their customers. Any queries should be conducted against “whois.melbourneit.com” – [line 6]
  • The abcexample.com domain was initially registered (i.e. created) on the 26th October 2001, and must be renewed before the 26th October 2005.

In order to get more information about the domain registration of abcexample.com we must query the managing WHOIS server – whois.melbourneit.com. The response is as follows:

1. Domain Name abcexample.com
2. Creation Date 2001-10-27
3. Registration Date 2001-10-27
4. Expiry Date 2005-10-27
5. Organisation Name itsmysay.com
6. Organisation Address woodland House, seaton road
7. Arbroath, Angus
8. DD11 5SE
9. Tayside
11. Admin Name Technical Support
12. Admin Address Farringdon Road
13. London
14. EC1R 3BW
15. .
17. Admin Email helpdesk@easily.co.uk
18. Admin Phone 44020784100xx
19. Admin Fax 44020784174xx
20. Tech Name Technical Support
21. Tech Address Easily Limited
22.              Farringdon Road
23.              London
24.              EC1R 3BW
25. *
27. Tech Email helpdesk@easily.co.uk
28. Tech Phone +44.2078410070
29. Tech Fax +44.2078417460
30. Name Server ns0.byworkwise.com
31.             ns1.byworkwise.com


  • Both the creation and expiry dates appear to be one day older that that indicated in the query against the root .com server. The managing registration server should have same or earlier dates. The discrepancy is most likely due to the fact that melbourneit.com is located in Australian and thus operating in a different time-zone to the root .com server – [lines 2 & 4]
  • The organisation name refers to “itsmysay.com” with an address in Tayside UK – [lines 5-10]
  • Technical administration for the domain registration is directed to generic addresses related to “Easily Limited” (easily.co.uk), with UK address details pointing to London.
  • There are two name servers listed (ns0.byworkwise.com and ns1.byworkwise.com), both independent of both itsmysay.com and easily.co.uk – [lines 30-31]
  • Analysis of this name registration information reveals that the initial registration of abcexample.com was carried out in Australia, but is now managed by the third-party company, Easily Limited – located in the UK. We also note that the name servers for the domain are managed by another entity – byworkwise.com.
  • A quick examination of the byworkwise.com web site reveals that the name servers belong to “Blueyonder Workwise”. Relating this information to the network WHOIS registration information, we see that the name servers are related to the personnel who last changed the RIPE WHOIS details observed in the first worked example (ripe-admin@blueyonder.co.uk).

It is interesting to note that the ABC Example web site can be accessed using the www.abcexample.co.uk domain name. A query of the WHOIS server responsible for managing .co.uk domains (whois.nic.uk) reveals the following:

1. Domain Name: abcexample.co.uk
2. Registrant: itsmysay.com
3. Registrant's Agent: Easily Limited t/a easily.co.uk [Tag = WEBCONSULTANCY]
4. URL: http://www.easily.co.uk
5. Relevant Dates:
6. Registered on: 26-Oct-2001
7. Renewal Date: 26-Oct-2003
8. Registration Status: Renewal required.
9. Name servers listed in order:
10. dns0.easily.co.uk
11. dns1.easily.co.uk
12. WHOIS database last updated at 20:30:02 08-Nov-2003


  • The initial .co.uk registration date (26th October 2001) is the same as for the .com version – [line 6]
  • The renewal data has expired and ABD Example must re-register the domain name to keep it, or another organisation could purchase it – [lines 7-8]
  • There are two domain names associated with the .co.uk domain (dns0.easily.co.uk and dns1.easily.co.uk), both of which are controlled by easily.co.uk – the same organisation identified in the registration of the .com domain registration details – [lines 3, 10 & 11]

Security Issues and Advice

When focusing upon the “Internet Service Registration” analysis phase of a passive information gathering exercise, organisations should carefully review the detailed information returned. The primary security issues and advice include:

ISP SelectionFor most organisations, almost all network service-based information will be controlled and managed by the local ISP or Internet connectivity provider.  It therefore extremely important that a good relationship is established.

Before selecting or migrating to a new ISP, carefully review some of the registrations they manage and ascertain the level of information they disclose.  It should be fairly clear whether they follow security best practices, or could represent a future security risk to your organisation.  Lax security could result in social engineering attacks or loss of all IP-based Internet traffic (effectively causing a denial of service).

In addition, many organisations will rely upon their selected ISP to provide DNS name services.  It is vital that these hosted services be secure from an attack & penetration perspective as well as not disclosing volumes of information about their clients through unregulated zone-transfers.  Loss or alteration of DNS services can result in denials of service and possible hijacking of client connectivity through man-in-the-middle based attacks.

Address DetailsWhere possible use generic postal addresses for all registration details – preferably not the organisations main office address.  When possible, the use of PO Box numbers are recommended.  However, some ISPs or registrars will not accept PO Box numbers for addresses.  Alternatively, with permission the organisation’s accountant’s, their address may be used.
Real NamesNever use real names and email addresses in registration details.  Create and use role-specific names and email addresses such as “RIPE Admin” and RIPE@myorganisation.com.  Real names can be used in social engineering attacks, or automated brute-forcing attacks against other online services.
Phone NumbersWhere possible use a single, generic phone number for the entire organisation.  The phone receptionist should have available a list of appropriate contact names and numbers for any registration queries.  Ideally, the receptionist would take the contact name and number of the caller and pass it on to the appropriate internal technical contact instead of transferring the call to the internal technician.  To reduce the risk of war-dialling and other exchange based attacks, a national number (such as 0870 in the UK or 1-800 in America) could be used.
MNTNER AuthIt is extremely important that the highest level of authorisation method is used to manage MNTNER records.  Ideally, PGP should be used.

Failure to use strong MNTNER authorisation levels can lead to unauthorised alteration of registration details.  The effect could include loss of corporate Internet IP address ranges, and consequently all connectivity.  In addition, a careful attacker could cause subversion of all organisational clients, and present them with false services (such as a fake website to steal login information and credit card details).

When using non-PGP level MNTNER authorisation methods, it is important that the registration maintainers DO NOT select or use guessable passwords (nor passwords they use for other administrative tasks).

Expiry DatesIt is important to keep a careful track of the expiry dates of domain names the organisation has registered.  Failure to do so can easily result in someone else (an attacker or competitor) taking ownership of the domain name and using it themselves for whatever purpose.

Ideally, most organisations should review this registration information as a monthly or bi-monthly process

    Copyright 2001-2007 © Gunter Ollmann