Ever heard of noodling? It’s a really fun and exciting way to fish—if you’re borderline insane, have no fear of losing a finger, hand, or (in some cases) your life, and feel that the best way to even things up in the hunt is to actually get in the water with your prey. Noodling has been around for a long time and involves catching catfish—sometimes giant, triple-digit-pound catfish—with your bare hands.

The idea is pretty simple. The noodler slowly crawls along the riverbed close to the bank and searches for holes. These holes can be up in the clay siding of the river, inside a hollow tree trunk, or under rocks, and they are used by catfish during daylight hours to rest and prepare for the evening hunt for food. Once the noodler finds a hole, he reaches his hand, arm, or (depending on the depth of the hole) leg into the hole hoping that a fish hiding in the hole bites onto the hand, arm, or leg so it can then be drug out of its hiding place. Of course, occasionally there’s something else in the hole. Like a snake, alligator, beaver, turtle, or other animal capable of lopping off a digit or two, but hey—what’s life without a few risks?

Sometimes the hole is so deep the noodle has to go completely underwater to battle his prey. And sometimes it even leads to a giant underwater lair, with multiple escape routes for the catfish. In this case, a team of noodlers is needed to cover up every exit hole from the catfish lair. And, of course, to block the exit holes they don’t use rocks or pieced of board; instead, they cram their hands, arms, legs, and every other body part into the openings. As the head noodler goes in for the fish, it will ram into and bite everyone else while it’s looking for an escape route—because, if nothing else, noodling is about sharing.

No, I’m not making this up. Noodlers catch dinner by having the fish bite onto their hands and then dragging them out of their holes up to the boat, the stringer, and eventually the frying pan. They seek out targets, slowly examine and map out every potential avenue in, and take risks to bring home the prize. Occasionally, as just mentioned, they even use a team to get things done. So, perhaps this may be a weird analogy to kick off your system hacking efforts, but after all this time preparing, aren’t you ready to get in the water and get your hands dirty? Even if it means you may get bit? Maybe we have more in common with noodlers than we thought.

This is the chapter where I start talking about actual system hacking. If you skipped ahead, go back and check those riverbank holes I covered in the first few chapters. There’s muddy water up ahead, and I don’t want any accidents.

Getting Started

Before getting started in actual attacks against the system, it’s pretty important that we take stock of where we’re at. Better stated, we should take stock of where we should be before attacking a device. We should, at this point, have already gone through footprinting, scanning, and enumeration. We should already have a good high-level view of the entire landscape, including the network range and all that competitive intelligence we talked about earlier. We should have already assessed available targets, identified services and operating systems running on the network, and figured out security flaws and vulnerabilities we might find interesting. In short, we should be channeling Sun Tzu and knowing our enemies (in this case, our targets) better than they know themselves.

If that’s all done, great—the attack phase will go relatively smoothly. If it’s not done, and not done thoroughly, you’re wasting your time moving forward and should go back to the beginning. Assuming you’ve paid attention and are following pen test principles with all this so far, let’s cover a few things you should know about the operating systems you’ll be targeting and take a look at the methodology for this whole thing.

Windows Security Architecture

Chapter 3 introduced enumeration and went through all the fun with RIDs and SIDs; however, there’s a lot more to get to, and this is the best place to get to it. The good news is, ECC seems to have cut way back on the OS architecture questions, so much of this is more for your edification as a budding ethical hacker—and don’t worry, I’ll point out the items of interest for you.

To properly break down Windows security architecture—at least the remaining parts of it we care about for our efforts here, anyway—it’s probably best we start by answering questions such as “Where are passwords stored on the system?” and “How does Windows authenticate users?” In answer to the first question, what would you say if I told you the passwords themselves aren’t stored anywhere on the machine? After all, it’d be kind of stupid to just stick them somewhere on a machine for anyone to grab and steal, right? Turns out that idea—storing passwords on a machine so they can be used for authentication while simultaneously figuring out how to protect them from theft—is what brought about the Security Accounts Manager (SAM) file.

Microsoft Windows stores authentication credentials in the SAM file, located in the C:windowssystem32config folder. Notice I avoided saying “passwords” because the purists lose their collective minds and start yelling semantic arguments at the book when I do. It’s actually more proper to say, “Microsoft Windows stores the hash value of passwords in the SAM file.” We’ve got a whole chapter regarding cryptography and encryption upcoming, but for now just know that a hash is a one-way mathematical algorithm that produces a unique output for a given input. Since it’s one way (in other words, you cannot simply reverse the hash value to the input it came from), storing the hash—and sending the hash across the wire for authentication—is a pretty good idea.

The biggest cause of concern for this method of password storage—and with hashing in general—is the complexity of the hash algorithm used. While you cannot reverse a hash, you can certainly steal it and, given enough time to run through variations with a password-cracking tool, figure out what the original input was. Some hash algorithms and methods are more secure than others, and Microsoft started out with one that became a hacker’s dream.

Hashing passwords in Windows has a long history. Back in the days when people rewound movies after watching them (those of you who remember the VHS-versus-Betamax debate are nodding here at the reference), Windows 2000 and Windows NT–type machines used something called LAN Manager, and then NT LAN Manager, to hash passwords. LM hashing would first take the password and convert everything to uppercase. Then, if the password was less than 14 characters, it would add blank spaces to get it to 14. Then the new, all-uppercase, 14-character password would be split into two 7-character strings. These strings would be hashed separately, with both hashes then combined for the output.

Obviously, this makes things easier for a hacker. How so, you may be asking? Well, if a password is seven characters or less (or uses only one or two character spaces in the second portion), this significantly reduces the amount of time required to crack the rest of it—because the LM hash value of seven blank characters will always be the same (AAD3B435B51404EE). For example, consider a password of M@tt123. The entire LM hash might look like this when we steal it: 9FAF6B755DC38E12AAD3B 435B51404EE. Because we know how the hash is created, we can split it in half to work on each side separately: 9FAF6B755DC38E12 is the first half, and AAD3B 435B51404EE is the second. The first half we put through a cracker and get to work. The second, though, is easily recognizable as the hash value of seven blank characters! This tells you the password is seven characters or less and greatly reduces the amount of time the cracking software will need to break the password.

Should you steal a SAM file and look at it, the results usually are pretty ugly (see Figure 5-1 for an example). There are a lot of characters and asterisks, and not much that seems to make any sense. In Windows Vista and later, the LM hash will be shown blank (the “NO PASSWORD” entries in the SAM file), and the NTLM hash will appear second.

Figure 5-1 SAM file

Of course, finding an easy-to-crack NTLM hash on your target system won’t necessarily be easy. You’ll first have to steal it (and by “it” I mean the SAM file), usually via physical access with a bootable CD or maybe even through a copy found on a backup tape. Even after it has been obtained, though, the addition of salting (additional protection by adding random data as additional input before being hashed, and something that’s largely outdated due to other security measures) and the use of better methods for authentication (NTLMv2 and Kerberos, if you sniff the hash value) make life for a password cracker pretty tough. Most administrators are wising up and forcing users into longer passwords with shorter timeframes in which to keep them. Not to mention, Windows has gotten much better at password security in the past decade or so. LM authentication has six levels available (0 is the Windows XP default, and 2 is the Windows 2003 default), and Kerberos transports the passwords much more securely than previously. Remember, though, you’re not hunting the healthy—you’re looking for the weak and overlooked.

Speaking of the healthy, we should spend some time talking about Windows default authentication protocol/method, Kerberos. Kerberos makes use of both symmetric and asymmetric encryption technologies to securely transmit passwords and keys across a network. The entire process is made up of a Key Distribution Center (KDC), an Authentication Service (AS), a Ticket Granting Service (TGS), and the Ticket Granting Ticket (TGT).

A basic Kerberos exchange follows a few easy but secure steps. The client first asks the KDC (which holds the AS and TGS) for a ticket, which will be used to authenticate throughout the network. This request is in clear text. The server will respond with a secret key, which is hashed by the password copy kept on the server (in Active Directory). This is known as the TGT. If the client can decrypt the message (and it should since it knows the password), the TGT is sent back to the server requesting a TGS service ticket. The server responds with the service ticket, and the client is allowed to log on and access network resources. See Figure 5-2 for a display of this exchange.

Figure 5-2 Kerberos in action

You’ll note that, once again, the password itself is never sent. Instead, a hash value of the password, encrypted with a secret key known only by both parties and good only for that session, is all that’s sent. This doesn’t mean the password is unbreakable; it just means it’s going to take a lot of time and effort. KerbSniff and KerbCrack are options, but be prepared—it’s a long, grueling process.

The Registry

Finally, we can’t end this Windows basics discussion without at least touching on the heart of all things Windows: the registry. The Windows registry is a collection of all the settings and configurations that make the system run. Hierarchical in nature, this “database of configuration databases” (as stated on more than a few Microsoft definitions of the registry) stores a variety of configuration settings and options. In it, you can find settings for low-level operating system components, applications running on the machine, drivers, the SAM file, and the user interface.

Two basic elements make up a registry setting: keys and values. A key can be thought of as a location pointer (much like a folder in the regular file structure), and the value of that key defines the setting. Keys are arranged in a hierarchy, with root keys at the top, leading downward to more specific settings. The root-level keys in the registry are as follows:

•   HKEY_LOCAL_MACHINE (HKLM) Contains information on hardware (processor type, bus architecture, video, disk I/O, and so on) and software (operating system, drivers, services, security, and installed applications).

•   HKEY_CLASSES_ROOT (HKCR) Contains information on file associations and Object Linking and Embedding (OLE) classes.

•   HKEY_CURRENT_USER (HKCU) Contains profile information for the user currently logged on. Information includes user-level preferences for the OS and applications.

•   HKEY_USERS (HKU) Contains specific user configuration information for all currently active users on the computer.

•   HKEY_CURRENT_CONFIG (HKCC) Contains a pointer to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetCurrentControlSetHardware ProfilesCurrent, designed to make accessing and editing this profile information easier.

There are a dozen or so values that can be placed in a given key location. These values can be a character string (REG_SZ), an “expandable” string value (REG_EXPAND_SZ), a binary value (REG_BINARY), or a host of other goodies. Remaining entries of note to you include the DWORD value (REG_DWORD—a 32-bit unsigned integer), the link value (REG_LINK—a symbolic link to another key), and the multisize value (REG_MULTI_SZ—a multistring value). For example, you can navigate to HKCUSoftwareMicrosoftNotepad and look at the lfFaceName value to see the default font type displayed in Notepad. Change the REG_SZ entry to the font name of your choice (TIMES NEW ROMAN, ARIAL, and so on), and Notepad will happily oblige the next time it opens. And if you’re annoyed by the consistent Windows Update pop-ups, screens, and slowdowns, navigate to HKLMSoftwarePoliciesMicrosoftWindowsWindowsUpdate and check out all you can adjust there.

Of course, these examples are just for fun, but obviously you can see how knowledge of the registry and its use can help you out greatly in your pen test job. If you can get access to the registry, you can set up all kinds of mischief on the device. Some of these keys even set up applications and services to run at startup or to keep trying to start if the pesky user (or his security tools) gets in the way. Some of the keys of great importance to you in particular (for your exam and your job) include the following:

•   HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServicesOnce

•   HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServices

•   HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce

•   HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun

Lastly, accessing and editing the registry is fairly simple (provided you have the right permission and access) with a variety of tools and methods. There is always the built-in command-line favorite, reg.exe, that can be used for viewing and editing. If you’re not seeking to impress someone with your command-line brilliance or, like me, you just prefer the ease of a GUI interface, you can stick with the regedit.exe or regedt32.exe application built into every Windows system. Both open the registry in an easy-to-view folder layout, but regedt32 is the preferred editor by Microsoft.

The MMC

Windows, by its nature, is an easy-to-use, intuitive (except maybe for Windows 8) operating system allowing most users to just sit down and go to work. Occasionally, though, there are a few tasks that administrative folks need to look at and take care of—especially in an enterprise environment. Sure, there are GUI-based options for their use, but there are actually command-line ones as well. This is not an MCSE book, nor is it intended to cover every single aspect of Windows administrative tasks, so we’re only going to hit a couple of those areas to give you a basic understanding of what you’ll need for your exam.

First on the list of new items to cover is the concept of Microsoft Management Consoles (MMCs). MMCs have been around for a long while in Microsoft Windows and are basically small GUI containers for specific tools. Each MMC holds an administrative tool for a given task, added in the console as a “snap-in,” and is named for that task. For example, there is an MMC named “Group Policy Editor” that, amazingly enough, allows an admin to edit the group policy. Other MMCs include Computer Management, Event Viewer, and Services, along with many more.

Linux Security Architecture

Although the great majority of machines you’ll see on your pen tests (and covered on your exam) are Windows boxes, Linux comes in more flavors than your local ice cream shop can come up with and is largely available for free, so you’ll see it pop up all over the place. Additionally, administrators seem to put a larger and larger percentage of their really important information and services on Linux servers, so if you see one, it’s probably a gold mine. When it comes to your exam, you won’t see many Linux questions at all—ECC seems much more “Windows focused” of late. Additionally, you won’t necessarily see questions specifically addressing Linux architecture; however, if you are familiar with Linux architecture, it will help out greatly in figuring out what some questions are actually looking for.

Any discussion on an OS has to start with the basics, and you can’t get more basic than the file system. The Linux file system isn’t that far removed from the NTFS layout you’re already familiar with in Windows—it’s just a little different. Linux starts with a root directory just as Windows does. The Windows root is (usually) C:. The Linux root is just a slash (/). It also has folders holding specific information for specific purposes, just like Windows. The basic file structure for Linux is shown in Figure 5-3.

Figure 5-3 Linux file structure

Here’s a list of the important folders you’ll need to know:

•   /   A forward slash represents the root directory.

•   /bin   The bin directory holds numerous basic Linux commands (a lot like the C:WindowsSystem32 folder in Windows).

•   /dev   This folder contains the pointer locations to the various storage and input/output systems you will need to mount if you want to use them, such as optical drives and additional hard drives or partitions. Note that everything in Linux is a file.

•   /etc   The etc folder contains all the administration files and passwords. Both the password and shadow files are found here.

•   /home   This folder holds the user home directories.

•   /mnt   This folder holds the access locations you’ve actually mounted.

•   /sbin   Another folder of great importance, the system binaries folder holds more administrative commands and is the repository for most of the routines Linux runs (known as daemons).

•   /usr   Amazingly enough, the usr folder holds almost all of the information, commands, and files unique to the users.

When you log into the command line in a Linux environment, you will start in your assigned directory and can move around simply by using the cd (change directory) command. You’ll need to, of course, define the path you want to use, so it’s important to know where you are. Many terminal sessions display the path just to the left; however, if you’re unsure, type pwd to see where you are and navigate from there. You can find other basic Linux commands of note in Table 5-1.

Table 5-1 Linux Commands

Security on files and folders is managed through your user account, your user’s group membership, and three security options that can be assigned to each for any resource: read, write, and execute. These security rights can be assigned only by the owner of the object. Typing the command ls -l will display the current security settings for the contents of the directory you’re in, which will appear like this:

The first column displays what the object is (the letter d indicates a folder, and blank indicates a file) along with the assigned permissions, which are listed as rwxrwxrwx. The read, write, and execute options are displayed for user, group, and all others, respectively. For example, the file named file1 has read and write assigned for the user, read-only for the group, and read-only for all others. The owner of the resources is also listed (user1) along with the assigned group (users).

These permissions are assigned via the chmod command and the use of the binary equivalent for each rwx group: read is equivalent to 4, write is 2, and execute is 1. For example, the following command would set the permissions for file1 to “r--rw-r--”:

Opening things up for everyone, giving all permissions to everyone, would look like this:

Obviously, knowing how to change permissions on a file or folder is an important little nugget for an ethical hacker.

Another important Linux fundamental deals with users, groups, and the management of each. Just as Windows has accounts created for specific purposes and with specific rights, Linux has built-in accounts for the management of the system. The most important of these user accounts is called root and is the administrative control of the system. All users and groups are organized via a unique user ID (UID) and a group ID (GUID). Information for both can be found within the /etc/passwd file. Running a cat command on the file displays lines that look like this:

Among other items in the file, you’ll find the users are listed. Root—the administrative “god” account of the system and the one you’re trying to get to—is listed first, with its UID and GID set to 0. User “matt” is the first user created on this system (UID and GID are set to 500), and “user2” is the second (UID and GID set to 501). Immediately following the user name is the password. Notice, in this case, the password is listed simply as “x,” indicating the use of something called the shadow file.

Passwords in Linux can be stored in one of two places. The first you’ve already met—the passwd file. If this is your chosen password storage location, all passwords will be displayed as a hash—an easily accessible, crackable hash—to anyone who has read privileges to the file. If you choose to use the shadow file, however, the passwords are stored and displayed encrypted (that is, hashed and salted). Lastly, and of special note to you, a budding ethical hacker, the shadow file is accessible only by root.

Just as with Windows, pulling the passwords offline and working on them with a cracker is your best bet for system “owning.” John the Ripper is one tool that works wonderfully well on Linux shadow files. The passwords contained within are actually hashes that, usually, have a salt assigned (also covered earlier). John will run through brute-force hashing and tackle the salts for you. It may take a while, but John will get it eventually. One final note: Weirdly enough, John barely gets a passing notice in the official CEH courseware. You’ll need to know it, of course, but chances are better than not you won’t even be asked about it.

This section wasn’t about making you a Linux expert; it was aimed at introducing you to the bare-bones basics you’ll need to be successful on the exam, as well as for entering the career field. As with everything else we’ve discussed thus far, practicing with a live system is your best option. Download a few distributions and practice—you won’t regret it.

Methodology

I know, I get it, so stop yelling at the book—you’re sick of methodologies, lists, and steps. Trust me, I’m sick of writing about them. However, they are essential to your exam and, yes, to your future job as an ethical hacker. You wouldn’t get on a plane if you saw the mechanics and pilots just toss away their preflight checklist, would you? Just as that checklist ensures problems are noted and taken care of before you’re 30,000 feet in the air, all these ridiculous sounding steps and phases ensure our hacking flight goes off without a hitch and makes sure we cover everything that needs to be looked at. You may not like them, but if you’re concerned about giving your customer—you know, the one paying you to pen-test their organization and the one putting their full faith and trust in you—what they need out of a pen test, you’d better get familiar with using them.

Remember in Chapter 1 when we covered ethical hacking phases? I’ve already walked you through the first phase (reconnaissance, a.k.a. footprinting) and spent a lot of time in the next two (scanning and enumeration), so now it’s time to get into the meat of the list. Gaining access is the next phase in the methodology and the next warm bath of terminology and memorization we’re slipping into. Maintaining access and clearing tracks are the remaining steps, which we’ll get to in this chapter and throughout the remainder of the book. If you were to examine these remaining phases, EC-Council has broken them down even further for your amusement, enjoyment, and edification.

In the gaining access phase, we’re supposed to take all that ammunition we gathered in the previous steps and start blasting the target. In EC-Council’s view of the world, that means cracking passwords and escalating privileges. Sure, there are tons of other attacks that can and should be hurled at a machine (many of which we’ll cover later in this book), but in this particular phase, CEH concentrates on getting those pesky passwords figured out and escalating privilege once you do. So, don’t freak out if you’re flipping through this chapter thinking I’m ignoring all other access attacks; I’m just following EC-Council’s structure and view of the hacking world to help you in your study.

After privilege escalation, you leave the gaining access phase and move into maintaining access. Here, the objective is to set up some things to ensure you can come back to this target and play around later, and in ECC’s way of thinking that means executing applications and hiding files. The idea is to execute a few applications that provide long-term access (which of course bleeds you right into the maintaining access phase). Of course, doing all this leaves a horrible mess laying around for anyone paying attention to notice and use to catch you in the act. This then leads you nicely into the last phase—covering tracks.

This covering tracks phase is exactly what it sounds like: we’ve busted in, gotten control, and set up a way back in for later access, but now it’s time to clean up the mess so the owner doesn’t notice anything amiss. If we were breaking into a bank or a business, we’d probably sweep up all the glass (if we broke anything), wipe down fingerprints from anything we touched, and put the toilet seats back down if we had to go potty while we were inside (don’t look at me that way—thieves have to go, too). System hacking is no different, except maybe there’s no toilet to worry about. Cleaning up and wiping down simply means we take care of log files on the machine and do our best to cover our tracks.

So, there you have it, wrapped up in a neat little bundle and illustrated (hopefully clearly) in Figure 5-4. I know some of you are scratching your heads trying to figure out why I added hiding files to the maintain access phase, when it seems to any rational person to belong in the clearing tracks phase, but I have good reason for doing so: that’s how it’s covered in the official courseware and class. So don’t blame me. And once we know what we’re supposed to do, we’re ready to dive into how to do it. But first, we still have a little background knowledge to cover: one, because it’s testable, and, two, because you really need to know this before moving forward.

Figure 5-4 System attack phases

Hacking Steps

The gaining access phase, by its own definition, requires you to grab authentication credentials of some sort to gain access to the device. Since a password associated with a user name marks the most prevalent authentication measure, it follows that password attacks should take up the majority of our time here. Sure, there are other ways to affect the changes and gather the information you’ll want on a pen test, but we’re trying to stick with the methodology here, and, actually, it kind of makes sense. To put everything together in some sort of logical order, we’ll first cover some basics regarding the lowly password itself and then discuss some of the attacks we can carry out against it.

Authentication and Passwords

Authentication has always revolved around three things for the individual: something you are, something you have, and something you know. The something you are measure regards using biometrics to validate identity and grant access. Biometric measures can include fingerprints, face scanning, voice recognition, iris scanning, and retina scanning. While biometrics seems like a panacea for authentication efforts, there are issues in dealing with it. The great thing about using biometrics to control access is it’s difficult to fake a biometric signature (such as a fingerprint). The bad side, though, is a related concept: because the nature of biometrics is so specific, it’s easy for the system to read an attempt as a false negative and deny legitimate access.

Most biometric systems are measured by two main factors. The first, false rejection rate (FRR), is the percentage of time a biometric reader will deny access to a legitimate user. The second, false acceptance rate (FAR), is the percentage of unauthorized access given by the system. The two measurements are charted together, and where they intersect is known as the crossover error rate (CER), which becomes a ranking measurement of biometric systems (the lower the CER, the better the system).

Another authentication measure includes something you have. This measure consists of a token of some sort (like a swipe badge or an ATM card) for authentication. Usually this also requires the user to use a PIN or password alongside it (making it two-factor authentication), but there are tokens that act on their own as a plug-and-play authentication measure. This comes with serious risks (if someone steals your token, they can access your resources), which is why a token is almost always used with something else.

Most security comes down to something you know, and that something is a password.

A password’s strength is usually determined by two major functions: length and complexity. There’s an argument to be made whether either one is better than the other, but there’s no argument (at least insofar as EC-Council and your exam are concerned) that both together—in one long and complex password—is the best. Password types basically are defined by what’s in them and can be made up of letters, numbers, special characters, or some combination of all. Passwords containing all numbers (for example, 12345678) or all letters (for example, AbcdEFGH) are less secure than those containing a combination of letters and numbers (for example, 1234AbcD). If you put all three together (for example, C3h!sgr8), you have the best you can get.

Complexity aside, the length of the password is perhaps even more important. Without a long, overly complicated discussion, let’s just apply a little deductive reasoning here. If a password cracker application has to guess only four characters, it’s going to take exponentially less time than trying to guess five, six, or seven characters. Assuming you use nothing but alphabetic characters, upper- and lowercase, every character you add to the password raises the possible combinations by an exponent of 52. Therefore, the longer your password and the more possible variables you have for each character in it, the longer it will take a password-cracking application (or, in modern systems, a distributed system of machines cracking passwords) to decipher, and the more secure you’ll be.

When it comes to passwords, just remember there’s no real magic solution in securing your resources. If they’re overly long and complex, users will forget them, write them down carelessly, and open themselves up to social engineering attacks on resets. If they’re too simple, password crackers can have a field day in your environment. The best you can do is stick with the tips provided here and try to walk that line between security and usability as best you can.

Lastly, another exceedingly important point involving passwords that is often overlooked by security professionals is the existence of default passwords. Default passwords are put in place by the manufacturer to allow the installing administrator to initially log in and set up the device or service, and these are sometimes simply forgotten about after installation. Routers, switches, wireless access points, database engines, and software packages all come installed with default passwords, and any hacker worth her salt will try at least a few iterations as an easy way in. Search engines are very helpful in this regard—just search for “default password lists” and you’ll see what I mean. A few resources to get you going include http://cirt.net, http://default-password.info, and http://open-sez.me.

Password Attacks

ECC defines four main attack types for password cracking: non-electronic, active online, passive online, and offline. The non-electronic attack is so powerful and so productive I’m going to devote an entire chapter to it later. Social engineering takes on many different forms and is by far the best hacking method ever devised by humankind. When you’re trying to crack passwords, the absolute best way to get one is just simply ask the user for it. Phrased the right way, when the user believes you to be someone from the IT department or a security agent, asking users flat out for their passwords will work more often than you’d think. Other productive methods include shoulder surfing (looking over the user’s shoulder—or from across the room or around the corner—to watch the keystrokes) and dumpster diving (combing through waste baskets and dumpsters for written passwords). We’ll cover much more on social engineering later—just stay tuned.

The active online attack is carried out by directly communicating with the victim’s machine and might possibly be the worst of the group from a terminology memorization aspect. Per ECC, active online attacks include dictionary and brute-force attacks, hash injections, phishing, Trojans, spyware, keyloggers, and password guessing. Many of these are easy enough to figure out. For example, a hash injection attack occurs, amazingly enough, when you steal a hash and inject it into a local session in hopes of accessing something. Password guessing is exactly what it sounds like—the attacker begins simply trying passwords—and Trojans or spyware can be installed on the system to steal passwords. It’s keyloggers and phishing here that make us all want to bang our virtual heads against the wall.

Keylogging is the process of using a hardware device or software application to capture the keystrokes a user types. With this method, it really doesn’t matter what authentication method you’re using or whether you’re salting a hash; the keystrokes are captured as they are typed, regardless of what they’re being typed for. If implemented correctly, it works with 100 percent accuracy, is relatively easy to do, and requires almost no technical knowledge at all.

Keyloggers can be hardware devices—usually small devices connected between the keyboard cable and the computer—or software applications installed and running in the background. In either case, keyloggers are an exceptionally powerful and productive method for scoring big hits on your target. Most users have no means to even realize a software application is running in the background, and most people rarely, if ever, look behind their computers to check for a hardware device. When was the last time you checked yours?

So how does a hardware keylogger constitute an active online attack? I suppose the theory is you are directly interacting with the device by manually attaching something to it. I know it’s a stretch but, hey, I never said any of the exam side was reality, did I? And if you think that’s bad, consider they include phishing in this as well.

Phishing is a social engineering attack whereby the attacker crafts an e-mail—usually with a bogus link for the user to click—and sends it to folks inside the target organization. What does this have to do with password cracking? I can honestly say, I’m not very sure, but ECC says it belongs here, so note it for your exam. We’ll cover more about phishing later on.

Another attack called out specifically by EC-Council, since we’re on the subject of active online attacks anyway, is the LLMNR/NBT-NS (Link-Local Multicast Name Resolution and NetBIOS Name Service) attack. This one is yet another example of a good idea designed to make our online lives easier and better being hijacked and used for devious purposes. The original idea was simple: we should keep name resolution as local as possible and/or provide a backup means for when DNS fails; therefore, DNS could use some help inside the subnet. Microsoft thought this was a great idea and came up with a couple Windows components that would act as alternate methods of host identification locally: LLMNR is based on the DNS format and allows hosts on the same subnet/local link to perform name resolution for other hosts, while NBT-NS identifies systems on a local network by their NetBIOS name.

How can this be leveraged, and what does it have to do with a password attack? Let’s say a bad guy has the means to get on your subnet and he spoofs the authoritative source for name resolution by simply responding to LLMNR or NBT-NS traffic. For example, say System A sends a broadcast asking if anyone knows the resolution for a particular resource on BRADFLSVR1. The attacker send a response saying, “Hey, yeah…that’s me. Just send all your traffic intended for BRADFLSVR1 this way.” This effectively poisons System A’s service, and now all traffic will flow to the attacker’s system. If the request requires identification and authentication, the user name and NTLMv2 hash may then be sent to the attacker’s system, which could then be collected through sniffers and other tools. After collection, the bad guy takes the hashes offline and starts cracking.

Tools capable of pulling this one off include NBNSpoof (www.mcgrewsecurity.com/tools/nbnspoof/), Pupy (https://github.com/n1nj4sec/pupy), Metasploit (www.rapid7.com/db/modules/auxiliary/spoof/llmnr/llmnr_response), and Responder (https://github.com/SpiderLabs/Responder.git). If you’re interested, mitigations for this attack include disabling LLMNR and NetBIOS (in local computer security settings or via Group Policy) if they are not needed in your environment, and using host-based security software to block LLMNR and NetBIOS traffic. This may or may not be tested on your exam, but it warrants an explanation here to cover all bases. Figure 5-5 lays out the whole attack for you.

Figure 5-5 LLMNR attack

Active online attacks oftentimes take much longer than passive attacks and also tend to be much easier to detect. If you happen to have identified a dinosaur Windows NT or 2000 machine on your target network, you can bang away at the IPC$ share and guess all you want. If you’re facing Windows XP and Windows 7 machines, the old “administrator” C$ share is still usually valid and, as always, you can’t lock out the true administrator account. You can try any variety of scripts available to run through user names and passwords against this share; just keep in mind it’s noisy and you’re bound to get noticed. Decent network and systems administrators will change the local administrator account’s name to something else (such as admin, sysadmin, or admin1), so don’t be surprised if you wind up locking out a few accounts while trying to get to the real one.

And don’t forget the old “net” commands. Here are a few to remember from your enumeration time:

•   net view /domain:domainname   Shows all systems in the domain name provided

•   net view \systemname   Provides a list of open shares on the system named

•   net use \targetipc$ "" /u: "   Sets up a null session

Combined with tools such as the NetBIOS Auditing tool (NAT) and Legion, you can automate the testing of user IDs and passwords.

A passive online attack basically amounts to sniffing a wire in the hopes of either intercepting a password in clear text or attempting a replay attack or a man-in-the-middle (MITM) attack. If a password is sent in clear text, such as in a telnet session, the point is obvious. If it is sent hashed or encrypted, you can compare the value to a dictionary list or try a password cracker on the captured value. During the MITM attack, the hacker will attempt to re-send the authentication request to the server for the client, effectively routing all traffic through the attacker’s machine. In a replay attack, however, the entire authentication process is captured and replayed at a later time—the client isn’t even part of the session.

Some passive online password hacking you’ve already done—just check back in Chapter 4, during the sniffing discussion. Other types of passive online password hacking can be done using specifically designed tools, such as the old-time favorite Cain and Abel (a Windows-based sniffer/password cracker). Turn Cain on while you’re surfing around for a day and I bet you’ll be surprised what it picks up. You can even set up Cain to sniff network traffic and then leave it alone: come back the next day and all the clear-text passwords, along with any hashes, will be stolen and ready for you.

And if you really want to see what a specific machine may be sending password-wise over the wire, try ARP poisoning with Cain (the button that looks like a radiation warning). The machine—or all of the machines if you spoof the default gateway MAC—will gladly send you everything! You can then use Cain for some offline brute-force or dictionary attacks on the password hashes you can’t read.

Basically, you monitor the victim’s traffic using a sniffer and packet-capture tool (Ferret), and a file called Hamster.txt is created. After the victim has logged into a site or two, you fire up Hamster as a proxy, and the cookies and authentication streams from the captured TXT file will be displayed. You simply click through them until one works—it’s that easy (of course, both machines must be on the same subnet). Installation of the tools can be a bit tricky, so be sure to check the help pages on the download site.

A surprising majority of sites use this method of session identification and are just as easily “hacked.” For those that don’t, a combination of URL variables, HTTP GETs, and other things will frustrate your efforts and cause you to try other methods—if this is, indeed, your goal. In practice, getting the session IDs from a website through XSS or other means can be tricky (Internet Explorer, for example, has done a really good job of locking down access to session cookies), but I believe this validates these discussions on physical security. If an attacker has uninterrupted physical access to the machine, it’s only a matter of time before the system is hacked, regardless of what security measures may already be in place. Internet Explorer plays with cookies differently, so there’s some trickiness involved, but this is an easy way to sidejack.

A few other tools of note are Ettercap, ScoopLM, and KerbCrack. Ettercap we’ve mentioned in previous chapters, but it warrants another few minutes of fame here. As with Cain, you can ARP poison and sniff with Ettercap and steal just about anything the machine sends out. Ettercap can also help against pesky SSL encryption (which prevents an easy password sniff). Because Ettercap is customizable, you can set it up as an SSL proxy and simply park between your target and any SSL site the victim is trying to visit. I watched this happen on my own banking account in our lab where we worked. My co-worker simply put himself (virtually) between my system and the SSL site, stole the session, and applied an Ettercap filter to pull out gzip compression, and the encoded strings were there for the taking. The only indication anything was out of sorts on the user’s side? A quick warning banner that the certificate needed looking at, which most people will click past without even thinking about it.

Speaking of SSL and its password-protecting madness, you should also check out sslsniff (www.thoughtcrime.org/software/sslsniff/). sslsniff was originally written to demonstrate and exploit Internet Explorer’s vulnerability to a specific “basicConstraints” man-in-the-middle attack but has proven useful for many other SSL hacks. (Microsoft has since fixed the original vulnerability.) Per the website, it is designed to act as a man in the middle for “all SSL connections on a LAN and dynamically generate certificates for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide.” That’s pretty good news for the budding pen tester indeed.

ScoopLM has a built-in password cracker and specifically looks for Windows authentication traffic on the wire to pull passwords from. KerbCrack also has a built-in sniffer and password cracker, specifically looking for port 88 Kerberos traffic.

Offline attacks occur when the hacker steals a copy of the password file (remember our discussion on the SAM file earlier?) and works the cracking efforts on a separate system. These attacks may require some form of physical access to the machine (not as hard as you’d like to believe in a lot of cases—trust me) where the attacker pulls the password file to removable media and then sneaks off to crack passwords at his leisure, but the point is you steal the hashes and take them somewhere else to bang on.

Password cracking offline can be done in one of three main ways: dictionary attack, hybrid attack, and brute-force attack. A dictionary attack is the easiest and by far the fastest attack available. This attack uses a list of passwords in a text file, which is then hashed by the same algorithm/process the original password was put through. The hashes are compared, and if a match is found, the password is cracked. Technically speaking, dictionary attacks are supposed to work only on words you’d find in a dictionary. They can work just as well on “complex” passwords too; however, the word list you use must have the exact match in it. You can’t get close; it must be exact. You can create your own dictionary file or simply download any of the thousands available on the Internet.

A hybrid attack is a step above the dictionary attack. In the hybrid attack, the cracking tool is smart enough to take words from a list and substitute numbers and symbols for alpha characters—perhaps a zero for an O, an @ for an a. Hybrid attacks may also append numbers and symbols to the end of dictionary file passwords. Bet you’ve never simply added a “1234” to the end of a password before, huh? By doing so, you stand a better chance of cracking passwords in a complex environment.

The last type is called a brute-force attack, and it’s exactly what it sounds like. In a brute-force attack, every conceivable combination of letters, numbers, and special characters is compared against the hash to determine a match. Obviously, this is very time consuming, chewing up a lot of computation cycles and making this the longest of the three methods. However, it is your best option on complex passwords, and there is no arguing its effectiveness. Given enough time, every password can be cracked using brute force. Granted, we could be talking about years here—maybe even hundreds of years—but it’s always 100 percent effective over time.

If you cut down the number of characters the cracker has to work with and reduce the number of variations available, you can dramatically reduce that time span. For example, if you’re in a network and you know the minimum password length is eight characters, then there’s no point in having your cracker go through all the variations of seven characters or less. Additionally, if you have a pretty good idea the user doesn’t like all special characters and prefers to stick with the “Fab Four” (!, @, #, and $), there’s no sense in having your cracker try combinations that include characters such as &, *, and (.

For example—and to stick with a tool we’ve already been talking about—Cain is fairly good at cracking Windows passwords, given enough time and processing cycles. For this demonstration, I created a local account on my system and gave it a (purposefully) short, four-character password: P@s5. Firing up Cain, I clicked the Cracker menu choice, clicked the LM&NTLM Hashes option on the left, and then clicked the big blue plus sign (+) at the top. Once all my accounts and associated passwords were dumped (simulating a hacker who had snuck in and taken them without my knowledge), I clicked my new user, cut down the number of possible characters for Cain to try (instead of all alphanumeric and special characters, I cut it down to ten, simply to speed up the process), and started the cracking. Forty-six minutes later, almost on the button, the password was cracked.

Of course, multiple tools are available for password cracking. Cain, KerbCrack, and Legion have already been mentioned. Another is John the Ripper—one of the more “famous” tools available. John is a Linux tool that can crack Unix, Windows NT, and Kerberos passwords. You can also download some add-ons that allow John to crack other passwords types (MySQL, for instance). LC5, the next generation of the old L0phtcrack tool, does an excellent job on a variety of passwords. Regardless of the tool, remember that dictionary attacks are fastest and that brute force takes the longest.

Privilege Escalation and Executing Applications

The only real problem with user IDs and password hacking is that, once you crack one, you’re stuck with the privilege level of the user. Of course, if you can get done what you need without bothering to escalate privileges, go for it. Sometimes, though, you just need more. If the user account is not an administrator or doesn’t have access to interesting shares, then you may not be much better off than you were before, and if you are so noisy in your attack that it garners too much attention, it won’t do you much good anyway. In this section, we’ll go over some of the basics on escalating your current privilege level to something a little more fun, as well as some methods you can apply to keep your hacking efforts a little quieter.

Unfortunately, escalating the privilege of an account you’ve hacked isn’t an easy thing to do—unless the system you’re on isn’t fully patched. Quite obviously, operating systems put in various roadblocks to prevent you from doing so. However, as you’ve no doubt noticed, operating systems aren’t released with 100 percent of all security holes plugged. Rather, it’s quite the opposite, and security patches are released with frequency to address holes, bugs, and flaws discovered “in the wild.” In just one week during the writing of this chapter alone, Microsoft released 24 patches addressing a wide variety of issues—some of which involved the escalation of privileges.

Basically you have four real hopes for obtaining administrator (root) privileges on a machine. The first is to crack the password of an administrator or root account, which should be your primary aim (at least as far as the CEH exam is concerned) and makes the rest of this section moot. The second is to take advantage of a vulnerability found in the OS, or in an application, that will allow you access as a privileged user. If you were paying attention about the importance of looking into vulnerability websites, this is where it pays off. In addition to running vulnerability scanners (such as Nessus) to find holes, you should be well aware of what to already look for before the scanner gets the results to you.

For example, in December 2009, both Java and Adobe had some serious flaws in their applications that allowed attackers to run code at a privileged level. This information spread quickly and resulted in hacking and DoS attacks rising rather significantly until the fix actions came out. Once again, it’s not something magic or overly technically complicated you’re attempting to do here; you’re just taking advantage of unpatched security flaws in the system. The goal is to run code—whatever code you choose—at whatever level is necessary to accomplish your intent. Sometimes this means running at an administrative level regardless of your current user level, which requires escalation and a little bit of noisiness, and sometimes it doesn’t. Again, in the real world, don’t lose sight of the end goal in an effort to accomplish something you read in a book.

The third method is to use a tool that will ideally provide you the access you’re looking for. One such tool, Metasploit, is an entire hacking suite in one and a great exploit-testing tool (in other words, it’s about a heck of a lot more than privilege escalation and will be discussed more as this book continues). You basically enter the IP address and port number of the target you’re aiming at, choose an exploit, and add a payload—Metasploit does the rest. The web front end is probably easier to use (see Figure 5-6), but some purists will tell you it’s always command line or nothing.

Figure 5-6 Metasploit’s main window

Metasploit has a free version and a pay-for version, known as Metasploit Pro. The framework you can download for free works perfectly well, but the Pro version, although expensive, is simply unbelievable. To say Metasploit is an important player in the pen testing/hacking realm is akin to saying Mount Everest is “kind of” tall. It’s a powerful pen testing suite that warrants more attention than I have room for in this book. Visit the website (www.metasploit.com) and learn more about this opportunity for yourself. There are tons of help pages, communities, a blog board, and more, to provide assistance. Trust me—you’ll need them.

Finally, the last method available may actually seem like cheating to you because it’s so ridiculously easy you might not have even thought about it. What if you just asked the current user to run an application for you? Then you don’t need to bother with hacking and all that pesky technology at all. This type of social engineering will be discussed in greater detail in Chapter 7, but it’s undeniably productive. You can simply put executable code in an e-mail and ask the user to click it—more often than not, they will! Craft a file to take advantage of a known Microsoft Office macro on an unpatched system and send it to them; most of the time they’ll click and open it! This is by far the easiest method available and probably will wind up being your most effective technique over time.

Executing Applications

So, you’ve figured out how to gain access to the system and maybe even gotten a way to escalate your privileges to that of administrator (root-level) status. Now what? Do you check that box and move on to the next target, or is there something more? It would be fairly deflating to come this far, touch the ring, and just leave, so I vote you stay and get some more work done.

Many times the act of escalating privileges requires you to execute an application or some sort of code, so this whole thing may seem a bit silly. However, just as I’ve stressed regarding all these methodologies and steps to this point, simply chalk this up to ensuring you get everything covered before the plane takes off appropriately, and read on.

Speaking of silly, EC-Council refers to this step as “owning” a system. Apparently gaining access to the machine and escalating your privileges to that of root level doesn’t mean anything at all. But remotely executing applications on the target machine? Now you’re really hacking—ethically, of course. The step of executing applications includes pretty much everything you can think of, hacking-wise. Obviously it applies to “malicious” programming—starting things such as keyloggers, spyware, back doors, and crackers—but the idea is the same regardless: once you have access to the system, execute at or above your privilege level to accomplish what you need to do.

I hesitate to add any more here, because oftentimes the application you’re executing is designed to ensure your continued access to the machine (which is a separate step altogether), so I’ll purposefully keep this section short. However, it is important to remember that the act of gaining root privilege and access isn’t really as important as getting the machine to do your bidding in the first place. New pen testers who come out of training oftentimes get caught up in the step-by-step process, instead of concentrating on what they’re really there to do, and their work suffers. As an ethical hacker, your goal is success—no matter how it comes. If the machine is doing what you want it to do, who cares about your root privilege level (or lack thereof)?

One thing we can do to wrap up is talk about a couple tools that may assist in executing on a remote machine and that you may see pop up on the exam. The tools in this phase are designed to deliver and execute applications within a network to remote systems. The idea is for administrators to have an easy way to deploy software and patches to machines under their control and care. There are hundreds and hundreds of these tools designed to make life easier on administrators that can be turned and used for dubious purposes. Examples of these include RemoteExec (www.isdecisions.com), PDQ Deploy (www.adminarsenal.com), and Dameware Remote Support (www.dameware.com). Regardless of the application, the idea is the same—remotely execute code on a machine, or several machines, to get something accomplished.

Hiding Files and Covering Tracks

So, you’ve spent your time examining potential targets, mapping out open ports, scanning for vulnerabilities, and prepping for an attack. After a few tries you successfully steal a password and find yourself sitting on the machine, logged on and ready to go. Now that you’re there and before you actually start executing anything, you need to be aware of all the attention that will be focused on your actions. Is the security administrator on the ball? Do they actively monitor the event logs on a regular basis? Is there a host-based intrusion detection system (HIDS) on the machine? How can you get information from it quietly and unnoticed?

This is where the ethical hacker, the guy working a pen test to help a customer see security flaws in their system, is at a huge disadvantage compared to his bad-guy counterpart in the real world. Stealth in hacking truly comes down to patience. Spend enough time, move slowly enough, and chances are better than not you’ll go unnoticed. Lose patience and try to upload every groovy file you see on the machine, and you’ll quickly find yourself firewalled off and trapped. The true bad guys out there have time on their hands and can take months to plan and pull off an attack. The pen tester has, by design, a limited amount of time to pull it all off.

But don’t lose heart. There are a few ways you can still sneak around and hide where you’ve been and what you’ve been up to. Some of it we’ve already talked about (such as evading network IDS by fragmenting packets and such), but there is also stealth to be had in hiding files and covering your tracks on the system. And that’s what we’ll cover in this section.

While it’s definitely more in the realm of academics and book knowledge (which is sure to bring a smile to my tech editor’s face), one way to hide files on Windows machines is through the use of an alternate data stream (ADS) in the form of New Technology File System (NTFS) file streaming. ADS is a feature of the Windows-native NTFS to ensure compatibility with Apple file systems (called HFS), not to mention the ability for loads of back-end features built into the OS and applications. ADS has been around ever since the Windows NT days and has held on all the way through to current Windows releases. NTFS streaming still works on all Windows versions, up through and including 10, believe it or not. No one in practice actually uses it, because it’s easy to spot and triggers all sorts of blasting warnings, but you will need to know it for your exam.

NTFS file streaming allows you to hide virtually any file behind any other file, rendering it invisible to directory searches. The file can be a text file, to remind you of steps to take when you return to the target, or even an executable file you can run at your leisure later. The procedure is simple. Suppose you want to put the executable badfile.exe in a plain-old readme.txt file. First, move the contents of the badfile file into the text file with a command like this: c: ype c:adfile.exe > c: eadme.txt:badfile.exe. Then just put readme.txt wherever you’d like and wait until time to put it into use. When ready to use the file, simply type start readme.txt:badfile.exe. If you really want to get fancy, create a link to the bad file by typing c:mklink innocent.exe readme.txt:badfile.exe and you can just execute innocent.exe any time you want.

If you’re a concerned security professional wondering how to protect against this insidious built-in Windows “feature,” relax—all is not lost. Several applications, such as LNS and Sfind, are created specifically to hunt down ADS. Additionally, Windows Vista introduced a groovy little addition to the directory command (dir /r) that will display all file streams in the directory. Lastly, copying files to and from a FAT partition blows away any residual file streams in the directory.

Although it’s not 100 percent certain to work, because almost everyone knows to look for it, we can’t neglect to bring up the attributes of the files themselves and how they can be used to disguise their location. One of these attributes—hidden—does not display the file during file searches or folder browsing (unless the administrator changes the view to force all hidden files to show). In Windows, you can hide a file by right-clicking, choosing Properties, and checking the Hidden Attribute check box. Of course, to satisfy you command-line junkies who hate the very thought of using anything GUI, you can also do this by issuing the attrib command:

Another file-hiding technique we’ll hit on later in the book (when I start talking encryption and cryptography) is steganography. Sure, we could discuss encryption as a hiding technique here as well, but encrypting a file still leaves it visible; steganography hides it in plain sight. For example, if you’ve gained access to a machine and you want to ferret out sensitive data files, wouldn’t it be a great idea to hide them in JPG files of the basketball game and e-mail them to your buddy? Anyone monitoring the line would see nothing but a friendly sports conversation. Tools for hiding files of all sorts in regular image files or other files include ImageHide, Snow, Mp3Stego, Blindside, S-tools, wbStego, and Stealth.

In addition to hiding files for further manipulation/use on the machine, covering your tracks while stomping around in someone else’s virtual play yard is also a cornerstone of success. The first thing that normally comes to mind for any hacker is the ever-present event log, and when it comes to Windows systems, there are a few details you should know up front. You’ll need to comb over three main logs to cover your tracks—the application, system, and security logs.

The application log holds entries specifically related to the applications, and only entries programmed by the developers get in. For example, if an application tries to access a file and the file has been corrupted or moved, the developer may have an error logged to mark that. The system log registers system events, such as drivers failing and startup/shutdown times. The security log records the juicy stuff, such as login attempts, access and activities regarding resources, and so on. To edit auditing (the security log won’t record a thing unless you tell it to), you must have administrative privileges on the machine. Depending on what you’re trying to do to the machine, one or all of these may need scrubbing. The security log, obviously, will be of primary concern, but don’t neglect your tracks in the others.

Many times a new hacker will simply attempt to delete the log altogether. This, however, does little to cover his tracks. As a matter of fact, it usually sends a giant blaring signal to anyone monitoring log files that someone is messing around on the system. Why? Because anyone monitoring an event log will tell you it is never empty. If they’re looking at it scrolling by the day before your attack and then come back the next day and see only ten entries, someone is going into panic mode.

A far better plan is to take your time (a familiar refrain is building around this, can’t you see?) and be selective in your event log editing. Some people will automatically go for the jugular and turn auditing off altogether, run their activities, and then turn it back on. Sure, their efforts won’t be logged in the first place, but isn’t a giant hole in the log just as big an indicator as error events themselves? Why not go in, first, and just edit what is actually being audited? If possible, turn off auditing only on the things you’ll be hitting—items such as failed resource access, failed logins, and so on. Then, visit the log and get rid of those items noting your presence and activities. And don’t forget to get rid of the security event log showing where you edited the audit log.

One last note on log files and, I promise, I’ll stop talking about them: Did you know security administrators can move the default location of the log files? By default, everyone knows to look in %systemroot%System32Config to find the logs; each will have an .evt extension. However, updating the individual file entries in the appropriate registry key (HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLog) allows you to place them wherever you’d like. If you’ve gained access to a system and the logs aren’t where they’re supposed to be, you can bet you’re in for a tough day; the security admin may already have eyes on you.

A few tools are available for taking care of event log issues. In Control Panel | Administrative Tools | Local Security Policy, you can set up and change the audit policy for the system. The top-level settings are found under Local Policies | Audit Policy. Other settings of note are found in Advanced Audit Policy Configuration at the bottom of the listings under Security Settings. Other tools of note include elsave, WinZapper, and Evidence Eliminator. Lastly, Auditpol (shown in Figure 5-7) is a tool included in the old Windows NT Resource Kit that may be useful on older systems. You can use it to disable event logs on other machines. The following should do the trick:

Figure 5-7 Windows audit policy

Rootkits

Finally, no discussion on system hacking and maintaining stealth/access on the machine can be complete without bringing up rootkits. Per ECC, a rootkit is a collection of software put in place by an attacker that is designed to obscure system compromise. In practice, a rootkit is software that replaces or substitutes administrator utilities and capabilities with modified versions that obscure or hide malicious activity. In other words, if a system has a properly introduced rootkit installed, the user and security monitors shouldn’t even know anything is wrong—at least until it’s too late to do anything about it. Rootkits are designed to provide back doors for the attacker to use later and include measures to remove and hide evidence of any activity.

There are, of course, as many rootkits names and types as you can conceivably come up with; however, some are more notable for us because EC-Council references them for your memorization. One such item is “Horsepill,” a Linux kernel rootkit inside “initrd” with three main parts: klibc-horsepill.patch (creates a new, malicious, run-init), horsepill_setopt (moves command-line arguments to the preceding), and hrsepill_infect (splats files). Another is “Grayfish,” a Windows rootkit that injects code in the boot record, creating its own virtual file system (VFS). Sirefef is also mentioned, but its definition lends more to malware on steroids: it’s defined as a “multi-component family of malware.” Others you may see referenced include Azazel, Avatar, Necurs, and ZeroAccess.

Per the CEH objectives, there are six types of rootkits:

•   Hypervisor level These rootkits modify the boot sequence of a host system to load a virtual machine as the host OS.

•   Hardware (firmware) These rootkits hide in hardware devices or firmware.

•   Boot loader level These rootkits replace the boot loader with one controlled by the hacker.

•   Application level As the name implies, these rootkits are directed to replace valid application files with Trojan binaries. These kits work inside an application and can use an assortment of means to change the application’s behavior, user rights level, and actions.

•   Kernel level These rootkits attack the boot sectors and kernel level of the operating systems themselves, replacing kernel code with back-door code. These rootkits are by far the most dangerous and are difficult to detect and remove.

•   Library level These rootkits basically use system-level calls to hide their existence.

In the real world, rootkits are discussed much more in the context of the ring in which they work. The term protection rings in computer science refers to concentric, hierarchical rings from the kernel out to the applications, each with its own fault tolerance and security requirements. The kernel is referred to as Ring 0, while drivers (Ring 1), libraries (Ring 2), and applications (Ring 3, also known as user mode) make up the surrounding rings. Although you probably won’t see them listed as such on your exam (yet, at least in the current version), it’s helpful to think of kernel rootkits working at Ring 0, application rootkits at Ring 3, and so on.

So how do you detect rootkits and what can you do about them? Well, you can certainly run integrity verifiers, and there are some heuristic, signature, and cross-view-based detection efforts that can show you whether a rootkit is in place. But the big question is, once you know, what do you do about it? While there are lots of things suggested, both in and out of official courseware, the real answer as far as your exam is concerned is to just reload the system. Use quality, trusted backups and reload. Unless it’s a BIOS rootkit. Or something on the firmware on your disk controller. Then…well…all bets are off.

Chapter Review

Microsoft Windows stores authentication credentials—hashes of passwords—in the SAM file, located in the C:windowssystem32config folder. The biggest cause of concern for this method of password storage, and so on, is the complexity of the hash algorithm used. Windows 2000 and Windows NT–type machines used something called LAN Manager, and then NT LAN Manager, to hash passwords. LM hashing puts all passwords in 14 characters, split into two 7-character groupings, and hashes both sides to make a full hash. If this process leaves the second seven-character side empty (that is, the original password was seven characters or less), the second half of the hash will always appear as AAD3B435B51404EE. In Windows Vista and later, the LM hash will be shown blank (the “NO PASSWORD” entries in the SAM file), and the NTLM hash will appear second.

Even after the password has been obtained, though, the addition of salting (additional protection by adding random data as additional input before being hashed) and the use of better methods for authentication (NTLMv2 and Kerberos, if you sniff the hash value) make life for a password cracker pretty tough. Windows default authentication protocol/method is Kerberos. Kerberos makes use of both symmetric and asymmetric encryption technologies to securely transmit passwords and keys across a network. The entire process is made up of a Key Distribution Center (KDC), an Authentication Service (AS), a Ticket Granting Service (TGS), and the Ticket Granting Ticket (TGT).

A basic Kerberos exchange follows a few easy but secure steps. The client first asks the KDC (which holds the AS and TGS) for a ticket, which will be used to authenticate throughout the network. This request is in clear text. The server will respond with a secret key, which is hashed by the password copy kept on the server (in Active Directory). This is known as the TGT. If the client can decrypt the message (and it should since it knows the password), the TGT is sent back to the server requesting a TGS service ticket. The server responds with the service ticket, and the client is allowed to log on and access network resources. Once again, the password itself is never sent. Instead, a hash value of the password, encrypted with a secret key known only by both parties and good only for that session, is all that’s sent.

The Windows registry is a collection of all the settings and configurations that make the system run. Hierarchical in nature, it stores a variety of configuration settings and options. In it, you can find settings for low-level operating system components, applications running on the machine, drivers, the SAM file, and the user interface. Two basic elements make up a registry setting: keys and values. A key can be thought of as a location pointer (much like a folder in the regular file structure), and the value of that key defines the setting. Keys are arranged in a hierarchy, with root keys at the top, leading downward to more specific settings. The root-level keys in the registry are HKEY_LOCAL_MACHINE (HKLM), HKEY_CLASSES_ROOT (HKCR), HKEY_CURRENT_USER (HKCU), HKEY_USERS (HKU), and HKEY_CURRENT_CONFIG (HKCC).

Key values can be a character string (REG_SZ), an “expandable” string value (REG_EXPAND_SZ), a binary value (REG_BINARY), or a host of other goodies. REG_DWORD is a 32-bit unsigned integer, REG_LINK is a symbolic link to another key, and REG_MULTI_SZ is a multistring value.

Some of the keys of great importance to you in particular (for your exam and your job) include the following:

•   KEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServicesOnce

•   HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServices

•   HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce

•   HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun

Linux starts with a root directory, just as Windows does. The Windows root is (usually) C:. The Linux root is just a slash (/). It also has folders holding specific information for specific purposes, just like Windows. A list of the important folders you’ll need to know includes /bin, /dev, /etc, /mnt, /sbin, and /usr. Important commands include cp, pwd, ifconfig, kill, adduser, ls, ps, and chmod. Security on files and folders is managed through your user account, your user’s group membership, and three security options that can be assigned to each for any resource: read, write, and execute. These security rights can be assigned only by the owner of the object. Typing the command ls -l will display the current security settings for the contents of the directory you’re in. These permissions are assigned via the chmod command and the use of the binary equivalent for each rwx group: read is equivalent to 4, write is 2, and execute is 1.

Passwords in Linux can be stored in one of two places—the passwd or shadow file. All passwords are displayed openly as hashes to anyone who has read privileges to the passwd file. In the shadow file, the passwords are stored and displayed encrypted, and shadow is accessible only by root.

System attacks fall in the “gaining access” ethical hacking phase. The full methodology includes reconnaissance, scanning, gaining access, maintaining access, and clearing tracks. Gaining access includes cracking passwords and escalating privileges. After privilege escalation, you leave the gaining access phase and move into maintaining access, which includes executing applications and hiding files. The covering tracks phase includes taking care of log files on the machine.

Authentication involves three main options: something you are, something you have, and something you know. Some authentication measures use something you are—biometrics (fingerprints and such)—to validate identity and grant access. Others use something you have, such as a token of some sort (like a swipe badge or an ATM card), for authentication. But most security comes down to something you know, and that something is a password.

Default passwords are in place by the manufacturer to allow the installing administrator to log in initially and set up the device or service, and they are sometimes simply forgotten about after installation. Routers, switches, wireless access points, database engines, and software packages all come installed with default passwords.

ECC defines four main attack types for password cracking: non-electronic, active online, passive online, and offline. The non-electronic attack involves social engineering practices, such as shoulder surfing and dumpster diving. The active online attack is carried out by directly communicating with the victim’s machine. Per ECC, active online attacks include dictionary and brute-force attacks, hash injections, phishing, Trojans, spyware, keyloggers, and password guessing. Active online attacks take a much longer time than passive attacks and are also much easier to detect. A passive online attack basically amounts to sniffing a wire in the hopes of either intercepting a password in clear text or attempting a replay attack or a man-in-the-middle (MITM) attack. Offline attacks occur when the hacker steals a copy of the password file and works the cracking efforts on a separate system.

Password cracking offline can be done in one of three main ways: dictionary attack, hybrid attack, and brute-force attack. A dictionary attack is the easiest and by far the fastest attack available, using a list of passwords in a text file, which is then hashed by the same algorithm/process the original password was put through. A hybrid attack takes words from a list and substitutes numbers and symbols for alphabetic characters—perhaps a zero for an O and an @ for an a. Hybrid attacks may also append numbers and symbols to the end of dictionary file passwords. A brute-force attack uses every conceivable combination of letters, numbers, and special characters compared against the hash to determine a match. It is very time-consuming, chewing up a lot of computation cycles, thus making this the longest of the three methods; however, given enough time, every password can be cracked using brute force.

A rainbow table is a huge compilation of hashes of every password imaginable. The amount of time it takes a cracker to work is dramatically decreased by not having to generate all these hashes over and over again. While GPU systems virtually eliminate their need, if you wish to make one, you can use tools like rtgen and Winrtgen.

There are two types of privilege escalation. Vertical privilege escalation occurs when a lower-level user executes code at a higher privilege level than they should have access to. Horizontal privilege escalation isn’t really escalation at all but rather simply executing code at the same user level but from a location that should be protected from access. There are four real hopes for obtaining administrator (root) privileges on a machine. The first is to crack the password of an administrator or root account. The second is to take advantage of a vulnerability found in the OS, or in an application, that will allow you access as a privileged user (DLL hijacking involves replacing legitimate DLLs with malicious copies in the application root folder). The third method is to use a tool that will ideally provide you the access you’re looking for (such as Metasploit). The last method is to just ask the current user to run an application for you.

The step of executing applications includes pretty much everything you can think of, hacking-wise. Obviously it applies to “malicious” programming—starting things such as keyloggers, spyware, back doors, and crackers—but the idea is the same regardless: once you have access to the system, execute at or above your privilege level to accomplish what you need to do. Examples of remote execution tools include RemoteExec (www.isdecisions.com), PDQ Deploy (www.adminarsenal.com), and Dameware Remote Support (www.dameware.com).

One way to hide files on Windows machines is through the use of an alternate data stream (ADS) in the form of New Technology File System (NTFS) file streaming. ADS is a feature of the Windows-native NTFS to ensure compatibility with Apple file systems (called HFS). NTFS file streaming allows you to hide virtually any file behind any other file, rendering it invisible to directory searches. Another file-hiding technique is steganography, which hides files in plain sight, buried as part of an image, video, or other file. Tools for hiding files of all sorts in regular image files or other files include ImageHide, Snow, Mp3Stego, Blindside, S-tools, wbStego, and Stealth.

In addition to hiding files for further manipulation/use on the machine, covering your tracks while stomping around in someone else’s virtual play yard is also a cornerstone of success. There are three main logs in the Windows OS to look at when covering your tracks—the application, system, and security logs. A few tools are available for taking care of event log issues. In Control Panel | Administrative Tools | Local Security Policy, you can set up and change the audit policy for the system. The top-level settings are found under Local Policies | Audit Policy. Other settings of note are found in Advanced Audit Policy Configuration at the bottom of the listings under Security Settings. Other tools of note include elsave, WinZapper, and Evidence Eliminator. Lastly, Auditpol is a tool included in the old Windows NT Resource Kit that may be useful on older systems. You can use it to disable event logs on other machines.

A rootkit is a collection of software put in place by an attacker that is designed to obscure system compromise. In other words, if a system has a properly introduced rootkit installed, the user and security monitors won’t even know anything is wrong. Rootkits are designed to provide back doors for the attacker to use later and include measures to remove and hide evidence of any activity. Some of the rootkits ECC is very concerned you know about are Azazel, Avatar, Necurs and ZeroAccess.

Per the CEH objectives, there are six types of rootkits: hypervisor level, hardware (firmware), boot loader level, application level, kernel level, and library level. Rootkits can be detected through a variety of tools and methods, but reloading from clean backups is the only real recovery method.

Questions

1.   Which of the following best defines steganography?

A.   Steganography is used to hide information within existing files.

B.   Steganography is used to create hash values of data files.

C.   Steganography is used to encrypt data communications, allowing files to be passed unseen.

D.   Steganography is used to create multimedia communication files.

2.   Which encryption standard is used by LM?

A.   MD5

B.   SHA-1

C.   DES

D.   SHA-2

E.   3DES

3.   Which of the following would be considered a passive online password attack?

A.   Guessing passwords against an IPC$ share

B.   Sniffing subnet traffic to intercept a password

C.   Running John the Ripper on a stolen copy of the SAM

D.   Sending a specially crafted PDF to a user for that user to open

4.   A user on Joe’s network does not need to remember a long password. Users on Joe’s network log in using a token and a four-digit PIN. Which authentication measure best describes this?

A.   Multifactor authentication

B.   Three-factor authentication

C.   Two-factor authentication

D.   Token authentication

5.   Which of the following best defines a hybrid attack?

A.   The attack uses a dictionary list, trying words from random locations in the file until the password is cracked.

B.   The attack tries random combinations of characters until the password is cracked.

C.   The attack uses a dictionary list, substituting letters, numbers, and characters in the words until the password is cracked.

D.   The attack use rainbow tables, randomly attempting hash values throughout the list until the password is cracked.

6.   While pen-testing a client, you discover that LM hashing, with no salting, is still engaged for backward compatibility on most systems. One stolen password hash reads 9FAF6B755DC38E12AAD3B435B51404EE. Is this user following good password procedures?

A.   Yes, the hash shows a 14-character, complex password.

B.   No, the hash shows a 14-character password; however, it is not complex.

C.   No, the hash reveals a 7-character-or-less password has been used.

D.   It is impossible to determine simply by looking at the hash.

7.   Where is the SAM file stored on a Windows 7 system?

A.   /etc/

B.   C:WindowsSystem32etc

C.   C:WindowsSystem32Config

D.   C:WindowsSystem32DriversConfig

8.   Examining a database server during routine maintenance, you discover an hour of time missing from the log file, during what would otherwise be normal operating hours. Further investigation reveals no user complaints on accessibility. Which of the following is the most likely explanation?

A.   The log file is simply corrupted.

B.   The server was compromised by an attacker.

C.   The server was rebooted.

D.   No activity occurred during the hour time frame.

9.   Which of the following can migrate the machine’s actual operating system into a virtual machine?

A.   Hypervisor-level rootkit

B.   Kernel-level rootkit

C.   Virtual rootkit

D.   Library-level rootkit

10.   After gaining access to a Windows machine, you see the last command executed on the box looks like this:

Assuming the user had appropriate credentials, which of the following are true? (Choose all that apply.)

A.   In Windows Explorer, a folder will appear under the root directory named BankFiles.

B.   In Windows Explorer, a drive will appear denoted as BankFiles (\MATTBOX) (F:).

C.   The mapped drive will remain mapped after a reboot.

D.   The mapped drive will not remain mapped after a reboot.

11.   An attacker has hidden badfile.exe in the readme.txt file. Which of the following is the correct command to execute the file?

A.   start readme.txt>badfile.exe

B.   start readme.txt:badfile.exe

C.   start badfile.exe > readme.txt

D.   start badfile.exe | readme.txt

12.   You see the following command in a Linux history file review:

Which of the following best describe the command result? (Choose two.)

A.   The process “someproc” will stop when the user logs out.

B.   The process “someproc” will continue to run when the user logs out.

C.   The process “someproc” will run as a background task.

D.   The process “someproc” will prompt the user when logging off.

Answers

1.   A. Steganography is designed to place information in files where it will lay hidden until needed. Information can be hidden in virtually any file, although image and video files are traditionally associated with steganography.

2.   C. LAN Manager (LM), an old and outdated authentication system, used DES, an old and outdated means for hashing files (in this case, passwords).

3.   B. Passive online attacks simply involve stealing passwords passed in clear text or copying the entire password exchange in the hopes of pulling off a reply or man-in-the-middle attack.

4.   C. Because Joe’s users need something they have (a token) and something they know (the PIN) this is considered two-factor authentication.

5.   C. The hybrid attack takes any old dictionary list and juices it up a little. It will substitute numbers for letters, inject a character or two, and run numerous hybrid versions of your word list in an attempt to crack passwords.

6.   C. LM hashes pad a password with blank spaces to reach 14 characters, split it into two 7-character sections, and then hash both separately. Because the LM hash of seven blank characters is always AAD3B435B51404EE, you can tell from the hash that the user has used only seven or fewer characters in the password. Because CEH recommends that a password be a minimum of eight characters, be complex, and expire after 30 days, the user is not following good policy.

7.   C. The SAM file is stored in the same folder on most Windows machines: C:WindowsSystem32Config.

8.   B. It’s a database server during normal business hours and there’s nothing in the log? Forget the fact a reboot would’ve showed up somewhere—none of the users complained about it being down at all. No, we think this one is going to require some forensics work. Call the IR team.

9.   A. The hypervisor-level rootkit is defined by ECC as one that basically replaces your physical OS with a virtual one.

10.   B, C. “Net use” commands were the rage back in the day. This command connects to a shared folder on MATTBOX. The shared folder is named BankFiles, and the mapping will display as a drive (F:) on the local machine. The persistent:yes portion means it will remain mapped forever, until you turn it off.

11.   B. The command start readme.txt:badfile.exe says “Start the executable badfile.exe that is hidden in the readme.txt file.” In other variants of this question, the bad guy could create a link and execute it simply by typing the link name (for example, mklink innocent.exe readme.txt:badfile.exe would create a link, and the bad file could be executed simply by typing innocent).

12.   A, C. The ampersand (&) after the command dictates that the process should run in the background. Without anything indicating a persistent process (that is, adding nohup before the process name), it will die when the user logs out.