John the Ripper is a fast password cracker, currently available for many flavors of Unix (11 are officially supported, not counting different architectures), DOS, Win32, BeOS, and OpenVMS. Its primary purpose is to detect weak Unix passwords. Besides several crypt(3) password hash types most commonly found on various Unix flavors, supported out of the box are Kerberos AFS and Windows NT/2000/XP/2003 LM hashes, plus several more with contributed patches.
Recently went closed source, but is still essentially free. Works with a client-server framework.
Nessus is the world’s most popular vulnerability scanner used in over 75,000 organizations world-wide.
Many of the world’s largest organizations are realizing significant cost savings by using Nessus to audit business-critical enterprise devices and applications.
Nmap (“Network Mapper”) is a free open source utility for network exploration or security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts.
Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. Nmap runs on most types of computers and both console and graphical versions are available.
Nmap is free and open source.
Can be used by beginners (-sT) or by pros alike (–packet_trace). A very versatile tool, once you fully understand the results.
Censorship is nothing new, but as many governments and law enforcement agencies tighten the noose, anti-surveillance solutions need to get creative.
The Tor Project, which runs the anti-surveillance Tor network, is one such being.
The non-profit runs a network designed to disguise the original locations of users through traffic and relay points, and is often used by journalists, activists, and those attempting to circumvent censorship.
Nima Fatemi, an independent security research and member of the Tor Project, highlighted in a recent blog post how users in countries such as China, Saudi Arabia, and Iran can still try to access the network.
As noted by Motherboard, governments including Saudi Arabia, Bahrain, Iran, Russia, and China often attempt to block the use of virtual private networks (VPNs) in an effort to keep an eye on their citizen’s online activities.
However, blocking Tor is a more complicated problem due to the use of volunteer-ran nodes and relays used to reroute traffic and disguise original IP addresses.
According to Fatemi, the Tor Browser spoofs the UserAgent identity feature to make users look alike and avoid spying, as well as fingerprint attacks. However, Tor is still an open network where anyone can get a list of relay points — and so governments can simply block them.
“They can simply get the list of Tor relays and block them,” Fatemi noted. “This bars millions of people from access to free information, often including those who need it most. We at Tor care about freedom of access to information and strongly oppose censorship.”
As a result, Tor has developed what the organization called Pluggable Transports (PTs). PTs are a type of “bridge” into the Tor network which “make encrypted traffic to Tor look like not-interesting or garbage traffic,” according to the developer.
If users already want to try out this censorship-thwarting tool, they are in luck — as PTs are already included in the Tor Browser.
Tor has provided a step-by-step guide, as shown in the image below:
Tor has hit the spotlight recently after a scandal involving one of the “core” members of the project’s development team rocked the very foundations of the organization. Jacob Appelbaum, a 33-year-old developer, stepped down from his position after being accused ofalleged inappropriate sexual misconduct.
While Appelbaum has denied the claim as a “calculated and targeted attack,” an investigation conducted by an external law firm found that “many people inside and outside the Tor Project have reported incidents of being humiliated, intimidated, bullied, and frightened by Jacob,” according to Tor executive director Shari Steele.
As a result of the scandal, the full Tor board has been replaced with new faces including security expert Bruce Schneier, executive director of the Electronic Frontier Foundation (EFF) Cindy Cohn, and Matt Blaze, a computer and information science professor at the University of Pennsylvania.
There’s a lot more to the web than the cat-video-laden sites we normally see. In fact, according to most sources, the web that we can typically get to via our browser of choice represents only a small fraction of what’s out there.
This deep web is an ocean of content that is not visible to search engines and cannot be easily stumbled over – existing as it does behind locked forms, encrypted connections, and hidden systems. Yet, even within the deep web there are darker corners, where the information isn’t just difficult to find, but actively hidden, and often for good reason.
This is the dark web, the stuff of breathless news reporting and nervous collar-fingering in the halls of power. And on the dark web, along with people who legitimately don’t want the government – *any* government – peering over their shoulders, are those whose stock-in-trade are things best not discussed in polite company.
The dark web is the home of illegal sales and bot-net rental services. It’s a place you don’t get to by accident, and it exists because, if there’s anything we can guarantee about human nature, it’s that for every sunny plaza we build, there’ll be a dark alley around the corner.
And that same tendency towards misuse and misappropriation will inevitably affect that next great technology deployment, the Internet of Things (IoT). The IoT is likely to be the hacker’s dream come true. A massive expansion in technology and systems, with little oversight, no real rules, and rolled out in many cases by companies with little or no history is cybersecurity. The IoT will consist of billions of devices existing in every nook and cranny of our public, work, and private lives, constantly on, and yet without anything in the way of legislative or industry mandates to keep it safe and secure.
Most “things” will likely operate safely and securely without interference, but there will be some portion of the IoT that will attract the attention of the very same people and organizations who build botnets, steal IP, and carry out pay-for-DDOS attacks using the far less extensive internet we see now. If there is an IoT, a “dark IoT” will follow as inevitably as dusk follows dawn.
I suspect that the dark IoT will consist of a body of compromised devices that are either explicitly feeding information to illicit sources, or are perhaps laying dormant for some future use. Whether it’s commercial devices acting as vulnerable Achilles heels to a corporate network, or some city control system doing double time as bot nets, the uses for the dark IoT will evolve in the same way as the purposes for the dark web have changed.
Just like the dark web, the dark IoT will operate quietly, under the radar, without most of us knowing. And just like the dark web, once it exists, the dark IoT will likely be with us for a long, long time. Of course, the better security we build into devices now, and indeed, the better able we are to detect when a device is compromised, the more we can manage the growth of a dark IoT. Rather like weeds in a garden, it’s far easier to control the initial growth than it is to eradicate them once they are established.
The key here, I believe, is to establish a method that enables us to do two things:
1. Monitor the lifecycle and behavior of devices so that we can better understand when and if they have been compromised. This will especially important for IoT devices that are within or around critical infrastructure.
2. Establish method of updating security (or simply taking the device offline) once we can identify that a device has “gone over to the dark side.” This is actually more important than attempting to build in perfect security out the box, since the complexity of the IoT will probably preclude perfect security from the start line.
If we fail to do both, we are back to playing the same fruitless blame game we’ve been playing for the past decade when it comes to general cyber security – only on a much bigger scale.
The IoT will change much about the way we use technology, but if we want to keep some degree of security and privacy, we have to accept that the human tendencies embodied in the dark web represent something too fundamental for us to expect the IoT to change.
DMitry (Deepmagic Information Gathering Tool) is a UNIX/(GNU) Linux Command Line program coded purely in C with the ability to gather as much information as possible about a host.
DMitry has a base functionality with the ability to add new functions, the basic functionality of DMitry allows for information to be gathered about a target host from a simple whois lookup on the target to UpTime reports and TCP portscans.
The application is considered a tool to assist in information gathering when information is required quickly by removing the need to enter multiple commands and the timely process of searching through data from multiple sources.
Base functionality is able to gather possible sub-domains, email addresses, uptime information, TCP port scan, WHOIS lookups, and more.
The information is gathered with following methods:
- Perform an Internet Number whois lookup.
- Retrieve possible uptime data, system and server data.
- Perform a SubDomain search on a target host.
- Perform an E-Mail address search on a target host.
- Perform a TCP Portscan on the host target.
- A Modular program allowing user specified modules
Create an ascii text output of the results to the “filename”
specified. If no output filename is specified then output will
be saved to “target.txt”. If this option is not specified in
any form output will be sent to the standard output (STDOUT) by
default. This option MUST trail all other options, i.e.
“./dmitry -winseo target”.
–i Perform an Internet Number whois lookup on the target. This
requires that the target be in the form of a 4 part Internet
Number with each octal seperated using the ‘.’ notation. For
example, “./dmitry -i 255.255.255.255”.
–w Perform a whois lookup on the ’host’ target. This requires that
the target be in a named character format. For example,
“./dmitry -w target” will perform a standard named whois lookup.
–n Retrieve netcraft.com data concerning the host, this includes
Operating System, Web Server release and UpTime information
–s Perform a SubDomain search on the specified target. This will
use serveral search engines to attempt to locate sub–domains in
the form of sub.target. There is no set limit to the level of
sub–domain that can be located, however, there is a maximum
string length of 40 characters (NCOL 40) to limit memory usage.
Possible subdomains are then reversed to an IP address, if this
comes back positive then the resulting subdomain is listed.
However, if the host uses an asterisk in their DNS records all
resolve subdomains will come back positive.
–e Perform an EmailAddress search on the specified target. This
modules works using the same concept as the SubDomain search by
attempting to locate possible e–mail addresses for a target
host. The e–mail addresses may also be for possible sub–domains
of the target host. There is a limit to the length of the e–
mail address set to 50 characters (NCOL 50) to limit memory
–p Perform a TCP Portscan on the host target. This is a pretty
basic module at the moment, and we do advise users to use some‐
thing like nmap (www.insecure.org/nmap/) instead. This module
will list open, closed and filtered ports within a specific
range. There will probably be little advancement upon this mod‐
ule, though there will be some alterations to make it a little
more user friendly. There are also other options for this mod‐
ule that can affect the scan and its relative output.
–f This option will cause the TCP Portscan module to report/display
output of filtered ports. These are usually ports that have
been filtered and/or closed by a firewall at the specified
host/target. This option requires that the ’–p’ option be
passed as a previous option. For example, “./dmitry -pf tar‐
–b This option will cause the TCP Portscan module to output Banners
if they are received when scanning TCP Ports. This option
requres that the ’–p’ option be passed as a previous option.
For example, “./dmitry -pb target”.
–t This sets the Time To Live (TTL) of the Portscan module when
scanning individual ports. This is set to 2 seconds by default.
This is usually required when scanning a host that has a fire‐
wall and/or has filtered ports which can slow a scan down.
You can download DMitry here:
fping is a program like ping which uses the Internet Control Message Protocol (ICMP) echo request to determine if a target host is responding.
fping differs from ping in that you can specify any number of targets on the command line, or specify a file containing the lists of targets to ping. Instead of sending to one target until it times out or replies, fping will send out a ping packet and move on to the next target in a round-robin fashion. In the default mode, if a target replies, it is noted and removed from the list of targets to check; if a target does not respond within a certain time limit and/or retry limit it is designated as unreachable.
fping also supports sending a specified number of pings to a target, or looping indefinitely (as in ping). Unlike ping, fping is meant to be used in scripts, so its output is designed to be easy to parse.
The binary named fping6 is the same as fping, except that it uses IPv6 addresses instead of IPv4.
−a Show systems that are alive.
−A Display targets by address rather than DNS name.
−b n Number of bytes of ping data to send. The minimum size (normally 12) allows room for the data that fping needs to do its work (sequence number, timestamp). The reported received data size includes the IP header (normally 20 bytes) and ICMP header (8 bytes), so the minimum total size is 40 bytes. Default is 56, as in ping. Maximum is the theoretical maximum IP datagram size (64K), though most systems limit this to a smaller, system–dependent number.
−B n In the default mode, fping sends several requests to a target before giving up, waiting longer for a reply on each successive request. This parameter is the value by which the wait time is multiplied on each successive request; it must be entered as a floating–point number (x.y). The default is 1.5.
−c n Number of request packets to send to each target. In this mode, a line is displayed for each received response (this can suppressed with −q or −Q). Also, statistics about responses for each target are displayed when all requests have been sent (or when interrupted).
−C n Similar to −c, but the per–target statistics are displayed in a format designed for automated response–time statistics gathering.
shows the response time in milliseconds for each of the five requests, with the “−” indicating that no response was received to the fourth request.
−d Use DNS to lookup address of return ping packet. This allows you to give fping a list of IP addresses as input and print hostnames in the output.
−D Add Unix timestamps in front of output lines generated with in looping or counting modes (−l, −c, or −C).
−e Show elapsed (round–trip) time of packets.
−f Read list of targets from a file. This option can only be used by the root user.
–g Generate a target list from a supplied IP netmask, or a starting and ending IP. Specify the netmask or start/end in the targets portion of the command line.
−h Print usage message.
−i n The minimum amount of time (in milliseconds) between sending a ping packet to any target (default is 25).
−l Loop sending packets to each target indefinitely. Can be interrupted with Ctrl–C; statistics about responses for each target are then displayed.
−m Send pings to each of a target host’s multiple interfaces.
−n Same as −d.
−p <n> In looping or counting modes (−l, −c, or −C), this parameter sets the time in milliseconds that fping waits between successive packets to an individual target. Default is 1000.
−q Quiet. Don’t show per–probe results, but only the final summary. Also don’t show ICMP error messages.
−Q n Like −q, but show summary results every n seconds.
−r n Retry limit (default 3). This is the number of times an attempt at pinging a target will be made, not including the first try.
−s Print cumulative statistics upon exit.
−S addr Set source address.
−I if Set the interface (requires SO_BINDTODEVICE support)
−t n Initial target timeout in milliseconds (default 500). In the default mode, this is the amount of time that fping waits for a response to its first request. Successive timeouts are multiplied by the backoff factor.
−T n Ignored (for compatibility with fping 2.4).
−u Show targets that are unreachable.
−O n Set the typ of service flag ( TOS ). n can be either decimal or hexadecimal (0xh) format.
−v Print fping version information.
−H n Set the IP TTL field (time to live hops).
You can download fping 3 here:
Miranda is a Python-based UPnP (Universal Plug-N-Play) client application designed to discover, query and interact with UPNP devices, particularly Internet Gateway Devices (aka, routers). It can be used to audit UPNP-enabled devices on a network for possible vulnerabilities.
Miranda was built on and for a Linux system and has been tested on a Linux 2.6 kernel with Python 2.5. However, since it is written in Python, most functionality should be available for any Python-supported platform. Miranda has been tested against IGDs from various vendors, including Linksys, D-Link, Belkin and ActionTec. All Python modules came installed by default on a Linux Mint 5 (Ubuntu 8.04) test system.
Some of its features include:
- Interactive shell with tab completion and command history
- Passive and active discovery of UPNP devices
- Customizable MSEARCH queries (query for specific devices/services)
- Full control over application settings such as IP addresses, ports and headers
- Simple enumeration of UPNP devices, services, actions and variables
- Correlation of input/output state variables with service actions
- Ability to send actions to UPNP services/devices
- Ability to save data to file for later analysis and collaboration
- Command logging
root@kali:~# miranda -h
Command line usage: /usr/bin/miranda [OPTIONS]
–s <struct file> Load previous host data from struct file
–l <log file> Log user–supplied commands to log file
–i <interface> Specify the name of the interface to use (Linux only, requires root)
–u Disable show–uniq–hosts–only option
–d Enable debug mode
–v Enable verbose mode
–h Show help
You can download miranda-upnp here:
WOL-E is a suite of tools for Wake on LAN security testing related to the WOL features of network attached computers, this is now enabled by default on many Apple computers.
This allows you to easily scan for Apple devices on a network (based on their MAC addresses).
These tools include:
- Bruteforcing the MAC address to wake up clients
- Sniffing WOL attempts on the network and saving them to disk
- Sniffing WOL passwords on the network and saving them to disk
- Waking up single clients (post sniffing attack)
- Scanning for Apple devices on the network for WOL enabling
- Sending bulk WOL requests to all detected Apple clients
root@kali:~# wol-e -h
[*] WOL–E 1.0
[*] Wake on LAN Explorer – A collection a WOL tools.
[*] by Nathaniel Carew
Waking up single computers.
If a password is required use the –k 00:12:34:56:78:90 at the end of the above command.
wol–e –m 00:12:34:56:78:90 –b 192.168.1.255 –p <port> –k <pass>
Sniffing the network for WOL requests and passwords.
All captured WOL requests will be displayed on screen and written to /usr/share/wol–e/WOLClients.txt.
wol–e –s –i eth0
Bruteforce powering on WOL clients.
wol–e –a –p <port>
Place the address ranges into the bfmac.lst that you wish to bruteforce.
They should be in the following format:
Default port: 9
Detecting Apple devices on the network for WOL enabling.
This will output to the screen and write to /usr/share/wol–e/AppleTargets.txt for detected Apple MAC‘s.
Attempt to wake all detected Apple targets in /usr/share/wol–e/AppleTargets.txt.
This will send a single WOL packet to each client in the list and tell you how many clients were attempted.
You can download WOL-E here:
Linux and Unix systems are no different from Windows systems and can be enumerated as well. The difference lies in the tools and the approach. In this section you will take a look at a handful of the tools that have proven useful in exploring these systems.
The finger command is designed to return information about a user on a given system. When executed it returns information such as the user’s home directory, login time, idle times, office location, and the last time they received or read mail.
The command line for the finger command looks like this: finger <switches> username
Switches that can be used with the finger command include the following:
- -b removes the home directory and shell from the user display.
- -f removes header information from the display.
- -w removes the full name from the display.
- -l returns the list of users.
The rpcinfo command enumerates information exposed over the Remote Procedure Call (RPC) protocol.
The command line for rpcinfo looks like this:
- rpcinfo <switches> hostname
Switches that can be used with rpcinfo include the following:
- -m displays a list of statistics for RPC on a given host.
- -s displays a list of registered RPC applications on a given host.
The showmount command lists and identifies the shared directories present on a given system.
showmount displays a list of all clients that have remotely mounted a file system.
- The command line for showmount looks like this:
/usr/sbin/showmount [- ade ] [hostname]
Switches that can be used with showmount include the following:
- -a prints all remote mounts.
- -d lists directories that have been remotely mounted by clients.
- -e prints the list of shared file systems.