Unicorn-Scan is another port scanning tool. It creates a chrooted environment (userland) to protect you from the possibly hostile network you are scanning. It can be used from the command line, or from a PostgreSQL-powered frontend. We will show you the command-line version here. The following chart is a concordance from Nmap users from the documentation on the Unicorn-Scan project website:
A basic connect scan to find all open ports in a range using Unicorn-Scan is unicornscan -i eth0 -Ir 160 -E 10.0.0.012/32:20-600. If we break this up into sections, the command is as follows:
i eth0: It defines the interface eth0 on the Kali machine-Ir 160: Its has two options in a group-I: It is telling Unicorn-Scan to print to screen immediately as open ports are found-r 160: It is setting the scan rate to 160 ports per second (PPS)
-E 10.0.0.012/32:20-600: It is the target range- The Classless Inter-Domain Routing (CIDR) code shows a network mask of
/32bits, which means a single IP address - The port range is from
20to600:
The extremely verbose version of the same scan with -vvvv gives you a lot more information. Proto 6 is the TCP protocol, and Proto 17 is UDP protocol. The extremely verbose version is loading tests for a possible web server at port 80 (TCP) and several expected UDP set-ups: DNS at port 53; SIP protocol at port 5060; Microsoft Simple Service Discovery Protocol (SSDP) at port 1900; and Talkd, a service that allows two users to be logged in to the same machine, such as the situation that exists when two people are shelled into the same service, on port 518:
Kali comes with several applications for this. Whichever one you choose, choose it and use it. If you need to go back six weeks after the test is run to verify something, you'll be happy you did. Also, when testing a high security environment such as a network that must be either HIPPA or PCI compliant, these notes can be useful during your certification. Keep all your project files in one directory with the same framework. Furthermore, it is possible that your work may be used in court, either to litigate against your client, a third party, or you, yourself. Your notes are your only defense in the latter case. The following is a framework we use:
- Make a folder for the client organization.
- Then make a folder for the actual test with the date in the folder name. It is safe to assume that wherever you ply your trade, you will see the same clients over and over. If you are not seeing repeat business, something is wrong with your own business model.
ext-20150315translates to an external test conducted on March 15th, 2015. 20150315 is a Unix date which breaks out toYYYY/MM/DD. If you see Unix date stamps that look like20150317213209, that is broken down to the second. - Inside of that folder, set up evidence, notes, and scans-docs directories. All evidence collected and screenshots are dropped into the evidence folder. Notes from KeepNote are kept in the notes folder, and scans and other related documents are kept in the scans-docs folder. When we start conducting tests later in this book, you will see this framework being used:
Even if you work for only one company, keep each test's data separated and dated. It will help keeping track of your testing.
For the actual note-taking, Kali comes with several applications. Maltego is one of these tools and is capable of keeping all your data in one place. The authors' favorites are KeepNote and Maltego. You saw an introduction to KeepNote in Chapter 1, Sharpening the Saw. KeepNote is a simple note-taking application. As you run tests, keep copies of output from manual exploits, individual scan data, and screenshots. What makes this nice is you have the ability to format your data as you go, so importing it into a template later is just a matter of copy and paste. The next image is an excellent setup for Keepnote:
Notice the Project Notes page for general notes about the project, and individual pages under the targets folder for notes on each machine being tested.