Chapter 7: dis-card – Stealing The Network

Chapter 7 dis-card

by Mark Burnett

Temor is a good buddy, and I can trust him. He isn’t really a hacker; he is a businessman. Our method is pretty straightforward: He finds the sites, and I break in, grab the credit card database, and place it on a drop site. He sells the database, and we both make money.

As for me, I’m a hacker. But you’ll never read about me defacing the Navy’s Web site or taking down CNN. Usually, my targets never know I’ve been inside. My pseudonym, dis-card, won’t ever be plastered across a hacked home page, and you’ll rarely find me hanging out in a public chat room. I really don’t exist; therefore, no one has any reason to fear me.

A hundred thousand credit card numbers—easy money. It’s by no means a large score, but certainly one that has become increasingly rare in the last couple years, as security awareness has increased. It is also uncommon nowadays for me to get in this fast.

Temor and I are well-known for providing quality lists. We always get top dollar. Temor brokers the deal to the vendors, who take our lists and sell them off in smaller chunks. Then vendors sell the cards to the carders for a huge profit. Sure, we could make more money selling directly, but then again, the vendors are usually the ones who end up in jail.

As for me, my anonymity keeps me safe. During the day, I put on my suit and head off to my job as a corporate network administrator. At night, I rip off the tie and sink into my other identity of dis-card.

I met Temor in an IRC chat room almost six years ago. I was a total newbie; no one had ever heard of me. Temor was an operator in a channel for carders. To us newbies in the chan, the ops were like gods. They always had a seemingly endless supply of cards, and most people in the channel fed off the few scraps they would toss out: old credit card numbers that had already been sold and resold so much that most of them had long been canceled. But I was learning to hack and started finding my own lists of card numbers. I wasn’t really interested in taking the risk of actually using a stolen card, but I knew what these lists were worth. What I wanted for myself was the +o that makes me a channel operator. I wanted to be one of the gods.

Remember, this was way back in the days of NT4, when very few hackers even bothered with Windows servers, partly because no one took Windows seriously and partly because no one really knew how to hack them well enough. But with five years of experience with Windows database administration and a couple more years in Windows networking, this was my domain. And I owned it.

This was my chance to prove myself. Looking back, I probably wasn’t as good as I thought I was. The confidence was partly a bluff. I was a good Windows hacker, but I still had a lot to learn. He gave me the URL, and I got lucky. In less than 60 seconds, I was in.

I was now one of them. From this point on, I threw out the scraps for others to feed on.

After a year, the group dissolved, mostly because several of the members had been arrested and were in jail. But Temor and I somehow escaped prosecution and went on to become quite skilled at obtaining card numbers. At one time, we estimated we had stolen more than 20 million cards. At first, we just traded them for shell accounts, access to warez sites, proxy lists, and so on. Once, someone sent me a top-of-the line Pentium 333 for a decent-sized list of cards.

Seeing an opportunity, Temor started making deals to sell our lists. Before we knew it, we started getting a backlog of orders to fill. While others out there were selling cards by the hundreds, we were selling them by the hundreds of thousands. In just three months, I made more money than I made in a year at my other job. Suddenly, I no longer cared about climbing the corporate ladder. I just sat back and became smug as a lowly network administrator, making the real money at 3:00 a.m. at the keyboard of my new P-333. Indeed, there was the constant fear of the FBI bursting into my bedroom at 6:00 a.m., but I brushed that aside and continued to develop my hacking skills.

Although that was just a few years ago, we talk about those times fondly as the “good “ol days.” Back then, we loved the attention. Now, attention is the last thing we want. Now, it’s all about the money.

Hacking certainly isn’t what it used to be. We must work harder than ever to find the good lists. Yes, we still do find them, but now the stakes are higher, and vulnerable sites are getting harder and harder to find. Many of my private 0-day exploits have been “discovered” by security researchers, and patches were distributed by the software companies. I used to at least be able to count on administrators not bothering to apply patches, but the increasing occurrence of worm attacks—like Code Red, Nimda, and SQLSlammer—has changed all that.

I used to take a Web site and run a CGI scanner to find which holes I would exploit. Now I have to find a site, wait for the next 0-day exploit, and try to hit the site before the admin applies the patch. And to make things worse, administrators actually look at their log files now, intrusion detection system (IDS) software is widely used, and even lame users bother installing some kind of personal firewall. What once required nothing more than a good Perl script now calls for stealth, deception, creativity, intuition, and enduring patience. It’s harder to hack, but I still have enough tricks to get myself in.


I keep a list of sites to hack. Temor and I pick the sites based on how secure we think they are and how unique their customer base is. Over the years, I have learned to gauge a network admin’s competence with a few simple network probes. When I find a target, I note the operating systems and software versions of their Web, mail, and FTP servers. I try a few of the most obvious exploits. If those don’t work, I just sit back and wait.

0-day exploits are more important now than ever. A great number of systems are patched within the first 24 hours of a vulnerability advisory. Windows even has a service for automatically downloading and installing hotfixes. Sure, there are still plenty of vulnerable systems on the Internet, but they’re harder to find. I closely monitor security mailing lists, Web sites, and download pages to learn of a vulnerability hours before anyone else. My advantage isn’t knowledge but speed.

Wednesdays are a big day for me, because that’s when Microsoft usually announces new vulnerabilities. The company used to get a lot of criticism for releasing advisories on Friday, leaving many networks exposed over the weekend. The Microsoft tech guys tried to avoid Friday releases, but soon found themselves scrambling to release the patches late Thursday night. Late Thursday night is essentially the same as Friday, so they finally made it a policy to try to release on Wednesdays.

Temor and I don’t consider ourselves experts at social engineering, but we do have some tricks that work remarkably well. Software exploits work fine, but can never match the information we gain through a good social engineering attack. I’m still amazed with the amount of information people are willing to give me once I’ve gained their trust.

It all starts with our diversions. Using one of our many owned systems around the world, we stage an attempted break-in to the target’s front-end servers. We try to use IP addresses from countries like Russia, Ukraine, and Romania. Our attempts need to be stealthy enough to not trigger any alarms, but be easily noticeable if someone is looking for them. In other words, we want them to find the evidence, but just not yet.

The diversions also serve as a red herring in case they ever do catch on to us. In fact, several times, we knew they were aware of us, so we flooded the server with attacks from all over the world. Singling out the real attack would be nearly impossible.

This is where I have the most fun. Introducing myself as the security administrator of a company (usually the real one I work for), I write a harshly worded e-mail, complaining that my IDS has identified one of their IP addresses as the source of an attack against my company’s network. I demand that they immediately cease and desist these attacks, or I will pursue legal action against them. I carefully word my e-mail using Internet security jargon and throw out scary words like forensics and investigation. I establish authority.

I give them my phone number and attach a list of made-up IDS log entries. Invariably, it doesn’t take long for my phone to ring.

“I got your e-mail, and this is very strange,” the admin on the phone usually tells me. “We own the IP address you gave us, but it isn’t even assigned to any of our PCs.”

“All I know is what the log files tell me,” I say. “In fact, the attacks are going on this very minute from the same IP address.”

I wait, as the admin falls silent on the other end, confused.

“Look, if you don’t take care of it, I will take this to the authorities,” I threaten.

If I’m successful in manipulating the target administrator, the conversation then continues with apologies and a promise to “look into it ASAP.”

Once I start hearing apologies, I know I own this admin. He sees me as an authority figure, a security expert. He is also so distracted and confused by my accusations that he lets his guard down, completely unaware that he is now prepared for phase two of the attack.

At that point, I slowly back off and eventually admit that I also got scans from another IP address. I give the admin the IP address of one of my diversion systems and try to make it sound like we are both victims here, together fighting a common enemy. This is what I call triangulation. We hang up, and I wait for the next call. It usually doesn’t take more than a few hours. The first place they will go is their Web logs.

“We think we found the problem. We looked in our logs and found the IP address that you mentioned,” he explains over the phone. “Our logs show they tried to break into our system just before attacking your server,” the admin tells me.

Giving him a way out, I ask, “So you think they spoofed your IP address to make it look like you attacked me?” I wait for a moment, hoping he doesn’t know how spoofing really works.

“Probably,” he boldly responds.

At that point, I mention that I have filed a report with law enforcement officials, providing this hacker’s information. I also explain that they made it clear they likely won’t be able to do much with this. I explain that we’re pretty much on our own, and that I’m probably not going to pursue the matter any further.

I then give the admin a few specific security pointers about servers and try to get involved in a conversation about the target organization’s security. After all, we wouldn’t want something like this to happen again. Depending on how successfully I’ve established the admin’s trust, he often reveals plenty of information about the network, including detailed information about its greatest weaknesses. One network admin even gave me his password so I could help him fix a vulnerability on his server.

We have a number of variants of the diversion, but the recipe is basically the same: confuse, threaten, delay, build trust, and triangulate. I’m not sure why the technique is so effective, but it consistently works. I imagine it’s kind of like how you feel when you’re pulled over for speeding, but somehow avoid getting a ticket. As soon as you pull off and are out of the police officer’s sight, you immediately speed up once again. The fear of getting a ticket, followed by the relief of not getting one tends to make you feel safe for a while. Besides, what are the chances of immediately getting pulled over again, especially now that you know where the cop is?

After the network admin thinks he knows where the hacker is, he lets his guard down. What’s amazing is that he just spoke on the phone with the real hacker.

The bad thing about a good exploit is that, as much as you want to use it, you can’t overuse it, because eventually someone else will discover it in their log files and report it to the software manufacturer. You want to save it for when you really need it, but you can’t sit on it too long, because someone else will find it, and you will lose your chance. This exploit that Microsoft just fixed was one of my favorites. But because it left such a huge footprint in the target’s log files, I considered it a one-use exploit. I sat on this one for over a year, waiting for that perfect opportunity to use it. Now it’s public knowledge.

Many people have the misconception that when Microsoft releases a security bulletin, it addresses a newly discovered vulnerability. In reality, many people likely already knew about and had been exploiting the hole for quite some time.

Another source of good exploits is fellow hackers. It’s particularly fun to trick other hackers into revealing their own exploits. Once a hacker bragged in an IRC channel that she could break into any Apache server she wanted. I argued with her for a bit, and then I challenged her to break into a particular Apache server. Of course, this was a server I already owned. I quickly fired up a sniffer and gave her the IP address. At first, I saw the usual probes that show up in millions of Apache log files every day. But suddenly, I saw a huge string of incoming characters, followed by an outgoing directory listing—likely a buffer overflow that spawned some shell code. I saved the sniffer logs and acted very impressed with the hacker’s superb skills. But in her eagerness to prove herself, she gave away a very decent private exploit.

But hackers aren’t the only good source of 0-day exploits. There are plenty of researchers who spend all day looking for holes in software. They find them, write up a security advisory, and their company gets a lot of press. Being “ethical hackers” they thoroughly test the issue and give the vendor sufficient time to release a patch. Sometimes, this process takes months. I own one well-known security researcher’s home PC and get at least a month to play around with new exploits before anyone else knows about them. One thing I found out is that security researchers often bounce their ideas off each other when developing exploits. So not only do I get all the vulnerabilities that this guy found, I get everything his friends found, too. How did I break into the PC of a security expert? Well, as the saying goes, the shoemaker’s kids always go barefoot.

Actually, what happened is that I first guessed his wife’s e-mail password. One thing led to another, and I eventually obtained his e-mail password as well. For months, I downloaded copies of his e-mails, making sure that my mail reader did not delete the mail from the server. Then one day, he sent an e-mail to his network administrator, wondering why his e-mail always showed up in Outlook as already being read. He was concerned, not because he suspected someone else was reading his e-mail, but because he was worried about missing something important, thinking he had already read it. Despite the fact that he was a very bright researcher, he wasn’t too smart. As you can imagine, I immediately stopped reading his mail. I suppose that he then e-mailed the admin, explaining that the problem had magically fixed itself. Nonetheless, during the time I was reading his e-mail, I gathered so much information about him and so many of his passwords that he will never be able to completely get rid of me.

I am tempted to change the admin’s desktop wallpaper or at least start ejecting the CD tray, but I know that my biggest advantage is making people feel like they haven’t been hacked. Sure, there was the diversion, but that will lead them nowhere, and they will quickly forget all about it.

After dumping the credit card database to a text file, I upload it to a drop site. Before I leave, I schedule a script to clean up all traces of my intrusion the next day, after the log files have been cycled. Easy money.

Of course, it isn’t always that easy. There was one network that took me nearly two years to penetrate. But it was well worth it, since there were 20 million credit card transactions in a single database. The first time I tried breaking in was way back when I was still learning. Being naive, I ran a commercial vulnerability scanner against the company’s Web server. Later that day, my dial-up Internet account stopped working. I called my ISP, and the customer service rep referred me to the Security department. The Security department rep said they had complaints about me scanning someone else’s network, so they canceled my account. I did my best at playing dumb, and I got my account reinstated. Having this experience didn’t deter me at all. In fact, it made the challenge more exciting. But it did teach me to be more careful in the future.

For months, I very slowly scouted out my target network, gathering every bit of information I could. I would move onto other networks, but this particular network became my hobby. It was kind of like that difficult crossword puzzle sitting on your coffee table—the one that you pick up occasionally on Sunday afternoons to fill in a word or two.

I slowly mapped out the network. In fact, my script probed one port on one IP address every five hours. Why at intervals of five hours? Because when my ISP canceled my account, the Security department later sent me the log files from the company’s IDS. I was able to determine what software my target used for intrusion detection. After some research, I found that any two events that occurred more than four hours apart would be difficult to correlate. To further evade detection, every few days, I bounced the scans from different IP addresses all around the world.

I documented every piece of Internet-facing hardware and software. In my research, I noticed that the admin liked to save money by purchasing hardware on eBay. eBay keeps track of everything you buy or sell. Searching for the network admin’s e-mail address, I found a list of nearly every piece of hardware on his network. I logged all this information, and even built a nice Visio diagram of what I knew about this network.

As months passed, I did find minor vulnerabilities, but never enough to get to the database. This company had extraordinarily strong security for the time, long before the days of Code Red and most administrators even heard of security patches. And their security didn’t just cover the perimeter, but they also practiced security-in-depth—a concept much talked about but hardly ever seen in the real world. This network was well-organized, and the administrators knew exactly what was going on at all times. Breaking into this network was extremely difficult. Even my best 0-day exploits failed to produce results.

Once I was able to upload a Trojan horse, but I couldn’t execute it. They quickly patched the hole and removed the file. I tried finding the home PCs of employees by searching e-mail headers found from Internet searches. This company even provided firewall hardware for the employees who worked from home!

Yet the more I failed, the more satisfying the reward would be once I succeeded.

It had been almost two years. At this point, I had gathered a few passwords, but there was no place I could use them. Then, finally, I got my break. I had a script that monitored the ARIN whois output for several companies. ARIN whois is a database that contains IP address ownership information. You can enter an IP address, and it tells you who owns it. You can enter a company name, and it will tell you which IP addresses they own. Once a day, my script would query a list of companies to see if they had registered any new IP addresses. This was in the time of the Internet boom, and technology companies were constantly expanding and increasing their Internet presence. My target company also was growing. One day, it moved office locations and obtained a new set of IP addresses.

This company’s firewall was the tightest I had ever seen. They were very specific about which IP addresses could communicate where and how and with whom. Ironically, this was their downfall. When the firewall was moved to the new network, it still contained the IP restrictions for the old network. Due to one bad firewall rule, every computer on the new network was completely exposed on the Internet. It was protecting all the old IP addresses, because it had not been updated for the new network. It took nearly three days for the company technicians to realize their mistake, but it was too late. Fifty million credit card numbers now sat on a dump site in the Netherlands.

But the company did notice an intrusion. Amazingly, another hacker broke in at exactly the same time as I did (I wonder how long he had been waiting). This other hacker was identified as the intruder, and the company announced that he had not successfully accessed the customer database.

It was a good hack. But in the end, I respected the folks at this company. They gave me a good challenge. Most of the time, I would hack one company after another, just hoping that someone would have good security. I was almost disappointed with how easy it all was. And it was not only easy, it was the same lame thing over and over again. Although the vulnerabilities themselves changed, the process was always the same. When I first started, it was the blank admin passwords. Then the ::$DATA exploit. Then +.HTR. Then Unicode. Then xp_cmdshell. Now it’s SQL injection.

What’s funny is that I’ve never needed to resort to some fancy theoretical exploit that security researchers talk about, because the script kiddy stuff usually works just fine. I’ve seen administrators go to great lengths to prevent man-in-the-middle attacks. But I’ve never actually used such an attack myself, I don’t know anyone else who has used one, and I don’t know anyone who was ever a victim of one. I’m not saying such prevention is useless, because by implementing these procedures, you can at least be sure you aren’t vulnerable to those types of attacks. But fix the more obvious stuff first. If you’re going to put bars on your windows, at least lock the front door.

Nevertheless, despite all the efforts a company makes to secure its network, there is always going to be the human factor.

Reverse-Engineering People

It’s the mantra of every tenderfoot hacker: People are the path of least resistance into a target network.

Social engineering owes much of its fame to Kevin Mitnick, who tricked many people into revealing access codes, passwords, and even proprietary-source code. But there is so much more to social engineering than pretending to be a help desk asking target employees to reset their passwords. And while effective, this type of social engineering is a highly specialized path paved with all kinds of risks. Remember, even Kevin Mitnick was arrested.

Still, social engineering does have its place. Much of the appeal of social engineering is the blatant theft of a company’s secrets in broad daylight, using nothing more than the hacker’s ingenuity and creativity. But sometimes, the more subtle and passive attacks can be just as effective.

One of my favorite pastimes is to let unsuspecting people do the dirty work for me. The key here is the knowledge that you can obtain through what I call social reverse-engineering, which is nothing more than the analysis of people. What can you do with social reverse-engineering? By watching how people deal with computer technology, you’ll quickly realize how consistent people really are. You’ll see patterns that you can use as a roadmap for human behavior.

Humans are incredibly predictable. As a teenager, I used to watch a late-night TV program featuring a well-known mentalist. I watched as he consistently guessed social security numbers of audience members. I wasn’t too impressed at first—how hard would it be for him to place his own people in the audience to play along? It was what he did next that intrigued me: He got the TV-viewing audience involved. He asked everyone at home to think of a vegetable. I thought to myself, carrot. To my surprise, the word CARROT suddenly appeared on my TV screen. Still, that could have been a lucky guess.

Next, the mentalist explained that he could even project his own thoughts to the TV audience. He explained that he was thinking of two simple geometric forms, and one is inside the other. The first two shapes that came to my head were a triangle inside a circle. “I am thinking of a triangle inside a circle,” he announced. Now I was impressed.

That TV program had a huge impact on me. It so clearly showed how predictable human beings are. We often think we are being original, but usually, we end up being just like everyone else.

Try asking someone to come up with a totally random number between 1 and 20. Most people will avoid either end of the range, such as 1 or 20, because those numbers do not look random. They also avoid clear intervals, such as numbers ending in 0 or 5. Since two numbers in a sequence, such as 11, don’t look very random, those will also be avoided. Most people will be more likely to pick a two-digit number than a single digit. People also tend to pick higher numbers within the range. So, with that in mind, you know that many people will pick 16, 17, or 18. Given a range of twenty possible numbers, a large majority will select the same three numbers. Everyone tries to be original in exactly the same manner.

How did all this help me become a better hacker? Because guessing for me is not a random shot in the dark. Instead, it is a calculated prediction of how victims will behave. The reason there are such things as lists of common passwords is because people, in an effort to be different, commonly select the same passwords over and over. Not only do I know what passwords they will commonly use, but also how they will name stuff, where they hide the important things, and how they will react under certain conditions.

Having successfully reverse-engineered human behavior, it is time to re-engineer people to behave according to our plans. It’s still social engineering, but instead of initiating contact with the target, we let them take action, as we passively observe. I call this passive social engineering.

For example, once I went to a large software exposition that was filled with booths of all kinds of PC software vendors. Before attending the event, I prepared a stack of recordable CDs, each with a small collection of various files. On each CD, I handwrote something that others, especially software vendors, would find interesting. I used labels such as Sales Data, Source Code, and Customer List. On each CD, I also recorded a small Trojan horse application that would automatically and silently install itself once the CD was inserted in the drive. Walking around the conference, I casually left these CDs in inconspicuous locations at vendor’s booths. I quickly discovered how effective this technique was as I walked away and overheard a vendor say, “Sales data? What’s this?” I could hardly contain my grin when I heard the CD tray on his laptop open.

The Trojan horse consisted of two parts: an installer and a Web server that mapped the entire hard drive to a nonstandard TCP port. The installer monitored the system’s IP configuration, waiting for an Internet connection with a publicly accessible IP address. As soon as it found one, it posted a simple encoded message to a public Web discussion forum I frequently visited. I just sat back, monitoring the forum for these posts. The subject was “Anyone know how to fix a blue-screen crash in NT?” To everyone else, the post looked like a lame newbie question, and it mostly went ignored, but the message body contained the encoded IP address of my Trojan Web server. The beauty of this technique is that if the Trojan ever were discovered, it would be impossible to trace back to me.

At that conference, I deployed 15 CDs. I got 12 responses. Most people fell for it, exactly as I had predicted.

Another example of a passive attack is one I did with a large shareware registration Web site. I couldn’t seem to get into anything too interesting, but I did gain full control of their DNS server. I tried installing a sniffer, but since the company was using a switched network, I had difficulty picking up any interesting network traffic. Then I decided to use an often-overlooked feature in Microsoft Internet Explorer, which is the ability to automatically detect a proxy server configuration without manual user intervention. To make things even more convenient, Internet Explorer has this feature enabled by default. However, when this configuration is located, it does not show up in Internet Explorer’s proxy setting dialog box. In other words, the user could be going through a proxy and never even know it. Even if the configuration were changed, few people would ever bother checking those settings.

To automatically configure a proxy, Internet Explorer searches for a host named WPAD in the current domain. Since I owned the DNS server, that was easy enough to add. Next, I had to start a Web server that contained a single file, wpad.dat, and install a small proxy server. This directed all Web traffic through the DNS server I owned. The next step was to fire up the sniffer and sit back and wait. I soon discovered that the company used a Web-based e-mail application, but users logged in using SSL. My next step was to provide a bogus login page, which simply involved browsing to the real page, saving the file, and then adding my own code. I configured the page to prompt the user for login information, save this information to a text file, and then pass this on to the real application. Users logged in for days, never suspecting they were logging in to my page the entire time.

After a few days, I checked back and found a large list of logins that eventually allowed me to gain access to the orders database, containing nearly a million credit card numbers. Again, easy money.

Another way people are predictable is how they type. If you ask someone to type the word admin twice, the typing sound will be nearly the same each time. Not only does one person type the same word the same way, many other people type the same words similarly.

Once I accidentally came across a password-guessing technique while on the phone with an administrator I was targeting. I went through the usual routine, telling her I had log file evidence of attacks from an IP address she owned. Apparently during our long conversation, the administrator’s password-protected screen saver had started, and she needed to log in again. I clearly heard the typing over the phone:

Now I knew through our e-mail correspondence that the admin’s user-name was, in fact, admin. Could I actually guess this administrator’s password just by hearing it? Over the phone, I clearly heard her type in her username, followed by a sequence of taps that sounded almost identical, except that it had a short delay and one extra tap at the end. I noticed that there was even a clear distinction, in the form of a short pause, between syllables of the word admin. But what was that last letter? Judging by how fast this admin was typing, I guessed that typing most keyboard characters wouldn’t involve any significant pause. But to type a number, you must move your hand up a row, certainly resulting in some delay. Was this administrator’s password something like admin5?

In studying passwords, I know that people often add one or two numbers at the end of a word, thinking they are being original. I took a huge list of passwords I had collected over the years, dropped them into a database, and ran some statistics. It turns out that the single most common number added to a password is the 1. The next most common number is 2, followed by 9, then 7, and so on, ending with the least common number, 8. I had previously found a terminal server on this company’s network, so I connected and tried to log in. The first two attempts failed—it wasn’t 1 or a 2. On the third attempt, I typed:

And I was in. The ultimate thrill in a passive social engineering attack is to get someone to type in her password and listen carefully to see if you can guess it.

People say I’m an excellent guesser. I’d say I’m an expert at predicting human behavior.


One of the more intriguing flaws of both software developers and network administrators is that they don’t seem to realize how even small information leaks can lead to huge security breaches. Still, they gratuitously leave bits of information all over the place.

Perhaps it’s a matter of perspective. When you’ve gone through all the steps to secure a server, it’s hard to imagine the usefulness of a few small bits of information. But hackers don’t see what you’ve already done to secure your network; we only see what’s left that you haven’t done. Developers and administrators also have some difficultly figuring out exactly what information is useful to hackers.

For example, few Windows administrators take measures to protect their Internet Information Server (IIS) log files. Typically, on IIS machines, I can find every log file ever created since the server was installed.

How would a hacker use log files?

Scenario 1

Once, I broke into the Web server for a company that sold high-priced telecommunications industry newsletters. The company had five different newsletters, and each one cost $1,000 per year for a subscription. I also noticed that the signup form included an option to have the company automatically rebill your credit card at the end of your subscription. That meant the company stored credit card numbers. But not just any credit card numbers—these were high-limit corporate cards.

After breaking into the Web server, I realized that it was a colocated server that had no connections to the corporate network. The company didn’t store the actual credit card information on the Web server, so it was evident that there wasn’t anything useful there. My next step was to figure out where on the Internet this company was really located. That’s where the IIS log files came in handy.

Browsing through the logs, it was clear that some IP addresses showed up far more often than others. I figured that this company’s employees would visit their Web site more than anyone else, and I was right. These IP addresses led me to a poorly secured DSL connection to their corporate office and to the secretary’s PC. Right on her Windows desktop was an Excel spreadsheet conveniently named rebilis.xls.

Scenario 2

Once I tried to break into a porn site. Normally, porn sites don’t produce good lists, because half the credit cards used to subscribe are already stolen. But porn sites do provide a good source of information that can be used in other attacks. I didn’t really get into the server, but I did locate—through some smart guessing—a directory where the admin saved the log files.

Many Web browsers have a feature where you can enter your username and password as part of the URL for convenience. If your username were joe and your password were joe99, you would enter the URL as follows:

What many people don’t realize is that each URL you browse to will show the previous URL as the Referrer string in the Web server’s log files. The log entry will look something like this:

I browsed through the logs and gathered a list of usernames and passwords. I sent that list through a script I made that tries each username/pass-word against a bunch of popular Web sites, such as Hotmail, Yahoo!, eBay, PayPal, E*Trade, and so on. All too often, people use the same usernames and passwords for several different accounts.

While it may be obvious why I would want someone’s PayPal account, what good is someone else’s Hotmail account? The answer is that when people sign up for things, they often get a confirmation e-mail with user-name, password, and sometimes other identifying information. These e-mails always advise the user to save this e-mail for future reference. The first place I go is the saved e-mails folder and see what other information I can gather. All because some porn site didn’t protect its log files.

Scenario 3

After owning a server, I like to browse through the log files to find evidence of other intrusions. I do this first, because I don’t want competition, and second, other hackers are usually careless enough to get caught. If a hacker gets caught and this scares a company into getting more secure, then that becomes a problem for me, too. I’d rather not have anyone else on my servers. So I dig through the logs and patch any holes.

There are other ways to find information besides log files. One of the first things I do after breaking into a server is to check the recent documents history, cookies, the Recycle Bin, and various most recently used (MRU) lists in the Windows Registry. I do this because I figure that if something is important, administrators will have likely accessed it within the past 30 days. From there, I find out which Web sites they visit and if they have installed an FTP client. It’s all seemingly unimportant stuff, but it’s information that will get me further into their network.

I gather all the information I find. In fact, my whole quest is information: numbers, names, addresses, dates, and so on. I stare at the names of thousands of consumers every day, but they all look the same to me now: nothing more than strings of characters, fields in a database, bits on the wire. I’m an excellent hacker, and my success is that no one knows how good I really am.

Once I shut down my PC, dis-card no longer exists. I go to bed, wake up the next morning, and go to work. The next night, I log in and start the whole process again. Easy money.