You see it. Deal.

More later. This is a stub.

Listen up, folks. I am about to share with you a practical way to own any corporate Windows network. Before you bitch, first let me tell you that I won't tell you anything you don't already know or is anything other than obvious. That said, this approach works 85-90% of the time. It is time tested. It works. I've done it many times. And if you try this outside of legitimate network vulnerability testing, I hope you go to prison for a long time. That said, on with the show...

First, the bigger the Windows network, the higher likelihood of success. You'll understand why in a moment.

Any company with greater than 100 workstations uses workstation images to deploy new machines. It's a fact of life. The trouble is, the machines are a bit too similar. No one thinks about the local Administrator account. Yes, the local admin account has the same password for every machine. This is the key. Sure, the local admin account password may change when they change the image. But more times than not, many/most/all local admin passwords will be the same.

Get access to a workstation. If you're a consultant, tell them you need one before you show up. That way, a nice fresh workstation will be waiting for you when you get there. If not, wait until everyone goes home and help yourself to one (or more). No matter. Get your hands on at least one.

Did you guess step two? Dump the hashes and crack them. If you're lucky, you'll have LANMAN hashes. If not, you'll have NT hashes. LM hashes fall faster than SCO's stock price. NT hashes can be cracked, but you better be prepared. Rainbow tables work for NT hashes too. Maybe you'll get lucky. Maybe you'll have a few hundred gigs of NT hash Rainbow tables. Whatever. Chances are good you'll have LANMAN hashes. (For you auditors out there, that's finding number two. Number one was common passwords for local Admin accounts.)

Step three is to see how many machines you can access with your new local admin password. Look up how to attach to other machines from the command line. Write a few batch files. You can test your newly stolen credentials against a couple of hundred machines in a few hours.

Find your Windows admin users. They may be smart enough to change the local admin passwords. With a big enough comapny, they won't all be smart enough. Keep plugging and keep good notes.

Review the file systems of the machines you can access. There may be some good nuggets inside. Maybe you'll find router passwords, maybe you'll find love letters to the admin's mistress. It's all valuable. (Keep good notes.)

When you find a Windows admin's workstation, bug it. You want to record all authentication sessions. There are many good keystroke loggers out there. If your paranoid, don't use them. Write your own.

Retrieve your Domain Admin creds and have fun. Make a new domain admin account. Call it something that fits in with the present members of the domain admin group. If the group is large (finding number four for you auditors), just make an account that looks natural. If not, make one that mimics another legit account. Many admins have extra accounts for whatever reason. If you see an account "bwilson", try "bwilson2". The admins will naturally think it belongs to Bill. Why did Bill make another account? Believe me, no one will ask him.

Obfuscation:

Change your mac address for each session. Better yet, change your network port.

Use another workstation you already own. Use an encrypted volume for your activities. Have the volume close after ten minutes of inactivity.

Steal the mac address of a lonely network printer. Use the printer's network jack too. Printers don't use 802.11x.

Use a wireless bridge. If they can't find you connected to a port, they can't find you.

Variations on a theme:

Tell the admin about the common local admin passwords. Chances are, he will make a job to run once a month to change all the local admin passwords. If the local admin passwords weren't all the same before, they are now. Be sure to thank him for making the vulnerability even bigger than it was before. (Hey Rob-The-Windows-Security-Guru: That one's for you, dumbass!)

Get stuck on a NetWare network? Consider yourself lucky. NetWare caches NDS credentials down to the local machine as a local user by default. Crack the local and you have NDS creds. Even if the NDS account is deleted, the local account stays, and may get you access to any machine the NDS user accessed when the account was active. I've accessed local workstations with two year old expired NDS accounts. Thanks Novell! (See what happens when you make interoperability with Microsoft a higher concern than security? With moves like that, you deserve to have Bill Gates eat your lunch.)

I will update this post whenever I feel like it, which may be never. If you have something to say about it, feel free.

-pegr

Let's see if we can game the journal system by posting a stub with a date/time marker, then editing it to reflect something prophetical after the fact. This is my stub. Stay tuned!

Mandatory prophetical placeholder... SCO will lose...

The original post is dated September 9, 2007. This edit (November 20, 2007) should reset that date. Let's see what happens... Hey! No date change! Now what can I predict after the fact? I'll have to wait for something big, then edit this post to reflect my uncanny ability to predict the future... This might be fun!

If anyone out there wantes to start a thread under this post to get in on the prediction (to be (n|g)amed later), now's your chance!

In considering Echelon, the world-wide signals intelligence program supposedly capable of recording, transcribing, and analyzing most any voice communication anywhere, I was intrigued by the technology it would take to do it. Better yet, can I make my own Echelon system? The answer is truly surprising, not in how simple it is to do, but in how utterly cheap it is, at least on a small scale.

First, we need a method to record telephone conversations. Since the conversations are to be processed by a computer, it makes sense to capture them with a PC at the beginning. Let's start with an interface device made to record phone calls to a standard cassette tape recorder. Here's one at everyone's "favorite" electronics store, Radio Shack. RS has been selling this kind of device for 30 years. It simply plugs into a phone line and toggles the remote switch on when a conversation is present. We don't care about the remote switch, we just want a tap that will convert a phone signal into something we can use with the microphone input on a sound card. This device is about $27 if you're too lazy to a) shop, or b) make your own.

Next, we need a bit of smarts on the PC side. While I'm a Linux user, I'll be using a Windows machine for this project because of the availability of off-the-shelf software components. What we need is a simple program that monitors the sound card microphone input, and when a voice signal is present, record the input to a file. When the input is no longer present, close the file and continue to monitor the input.

Well, it turns out there is just the utility to do this. Try this utility. This little program does exactly what I described.

So what do we have now? Well, we now have a system that will monitor a single phone line and record any phone conversations on that line to a wav file. The file name is encoded with the date/time the conversation took place. It even captures the DTMF of outgoing calls. Wow, our little Echelon system is coming together!

What to do now? Well, there are a few options. One is to simply have another script email any new files that appear in the recordings directory to you. I'm thinking a bit bigger, however. How about filtering the files through a voice/text converter, such as Naturally Speaking? Then, store away the transcription (along with the original recording) in a DB, and index by key words? In reviewing the features list of Naturally Speaking, the Preferred Edition (list for $199) has a feature that monitors a directory and auto-converts any new sound files that appear in it. Perfect! A complete batched system is within sight!

I haven't done this yet, but I can see no reason why you couldn't. If I can defeat my lack of organizational inertia (read lazyness), I'll update this post and let you know how it works!

Notice: In most states, you are only permitted to record phone conversations you are a participant in. Some states don't even let you do that. If you were to make a system like this and have it record phone conversations you are not a party to, you would very likely violate state and/or federal law. Yes, I understand the contradiction. No, I don't like it either.

So why would I make such a system if using it is illegal? It's more of an exercise to demonstrate that, whatever your take on government surveillance, phone tapping, key word searching, etc., you can remove from the argument whether or not they can do it. They positively and absolutely CAN, because I can.