Here is a quick paper (notes) about pen-testing a Windows Active Directory network. While I do know this paper covers only the lowest-hanging fruit, it seems that all too often, these lowest-hanging fruit are the most common fruit found in the wild.

I will add to make sure and grab the cached logins on the workstations attacked as well. Often, systems cache the default last 10 accounts, which almost always includes at least one admin-type account from desktop support or the person who made the image in the first place.

If you crack the local admin password, don’t just use it on other systems, but try to change obvious things in the password. If they’re not the same across the department or even the company, often desktop support has some sort of predictable password scheme based on the computer name or user name or department. Heck, even I had a predictable one back when I did support, but you really had to work to guess it and I left plenty of red herrings laying around (like having the second half of the hash crack into a known word or just lower-case letters to throw off how complex the first half was…)

I have protection on my SSH ports, but I wouldn’t mind more. Honestly, it can’t really hurt. This article by Kevin van Zonneveld on adding brute force protection to iptables (and your Ubuntu install) to help secure your SSH is a welcome addition. Far too often I read tidbits like this that stop at the first step: adding the iptables rules, and leave out all this other good stuff that Kevin goes into, like rummaging in cron to clean up rules, persisting the rules, and so on. I plan on adding this to my server in the next few. Thanks Kevin!

As a side note, it’s been over a year since I’ve been tinkering with iptables, so this will get me back on track as I’ve become rusty…

I just recently finished reading the excellent book, Security Metrics, Replacing Fear, Uncertainty, and Doubt, by Andrew Jaquith. Andrew has written a book, not that I would like to write someday, but a book about a topic that hasn’t been written about before, and he certainly has something (many things!) to say about it.

In fact, I have to make mention of a phrase that toally made me happy to see, since I rarely get such literary enjoyment from technical texts. On page 118, we have this gem: “perfidious outsourcers pilfering proprietary secrets.”

This book is definitely worthwhile for anyone who ever has to present security metrics as a part of their job. I would also recommend it for any security operations people who want to understand why some metrics should be gathered and how to better give your analysts and managers what they want. Likewise, any security operations people are likely the future analysts and managers anyway, so this makes for a very good early orientation to the important questions and how to appropriately answer them, let alone self-evaluate their own systems according to more appropriate metrics.

This Posted in general

Reading the Bejtlich interview sparked a thought. I read this in response to what makes a good network security analyst:

First, you need to want to beat the bad guys. If you are entering the security field because you heard a commercial on the radio advertising higher pay, you will not get far.

For some reason, this made me think of mention that Marcin made recently along with pdp about the movie Hackers and/or that old “hacking” culture that seems missing lately.

I need to give pdp proper kudos for coming out (hehe, read *that* link out of context why don’t ya?) about the movie’s influence on his life personally. There are few things more chic in digital security than bashing CISSP-holders, but bashing the movie Hackers is one of them. I love the movie for what it is, even if the details are dramatized heavily.

At any rate, pdp and Marcin are both (independently and cooperatively at the same time, I think) looking to revive a little bit of that curious innocence and culture that the hacking scene has seen slowly disappear. This sounds fun and cool, and while the industry, technology, and hackers-turned-professionals have largely matured, we can still have a hell of a lot of fun in our little geek circles and keep things immature and fun as a way to keep our lives from becoming overgrown with the burden of the daily IT/security overwork. Embrace your inner deviate, if not in action, at least in thought.

I think the bottom line is to just have enthusiastic, lifelong passion about this field. Live it, embrace it…but that last might be my hedonist side talking.

A quick note that Marcin has posted an interview with Richard Bejtlich over on his blog, ts/sci-security. Richard hosts what is definitely one of my favorite blogs, writes excellent books, and basically is one of those zen masters of his field of expertise, namely network monitoring and everything that goes into that discipline. Of all the people I would love to learn from and work side-by-side with for a few years to sponge up information, he’s near the top of the list, truly. I’d even fetch his coffee, give him massages, and frollic…er…someone stop this downward spiral..!

I’ve recently read two interested papers dealing with DNS-related attacks. First, Andrew Hay pointed over to a paper from the HoneyNet Project titled Know Your Enemy: Fast-Flux Service Networks. The HonetyNet Project is uniquely poised to do some things that most of us cannot autonomously do: monitor and trend threats. This position has allowed them to see Fast-Flux attacks first-hand, where DNS entries are changed dynamically to hide the source of malware downloads and controls. I’d be willing to bet this concept has been in use for quite some time, only many researchers fire off one or two lookups, report to the resulting domains, and that’s it. They likely never see the changes, and thus never realized they were not really doing much good.

I also see that Trusteer has a paper hosted describing cache poisoning against BIND 9 by leveraging predictable transaction IDs to update DNS caching servers surrepticiously. While this seems a bit exotic, I wouldn’t consider it too exotic. In fact, getting an outbound connection by an internal user shouldn’t be a huge problem, and that could be a big payoff if you can poison some major DNS entries. I think the biggest problem is just making sure you’re attacking a BIND 9 DNS caching server. I’ll dive into this paper more than my casual glance tonight. Considering our malware prevalence today, I think this can be easily leveraged by existing maldoers, but may require a bit more targeting than blanket blind malware. I’m interested if the paper goes into countermeasures or how to combat this.

Lastly, this paper hosted by InfosecWriters is an excellent primer on DNS and DNS security. I recently read a DNS paper that was really well written, and I think this was it. I’m not sure where I got the link from, however.

This article about the government’s opinion on P2P networks (they claim it is the cause of sensitive gov’t data being disclosed and is thus evil) is exactly what I thought when I first heard this story today. The use of P2P networks and applications is not the issue here. The issue is data protection and system control. Don’t let your organization-owned systems have P2P software on them (there are plenty of ways to tackle this both on the systems and the network!). And keep track of your data so people don’t bring it home and put it on little Stacy’s computer running 3 default all-shared P2P apps 24/7. Pound in that this activity is against policy. Stop slapping wrists and start meting out real punishments to the employees for such violations.

More fun web server tricks from Full-Disclosure today. Falling under the headings of “information disclosure” and “service fingerprinting” is an enabled server-status page in Apache. Go to your website and add “/server-status/” to the end to get the information, kinda like on apache’s site: http://www.apache.org/server-status

Computer help questions come in many flavors, and while many requests get dodged, there are times when influential or attractive (wink wink) people ask favors that you don’t want to dodge and would rather have a quick and impressive answer. One such situation involves the inevitable accidental file deletion or damaged disk recovery. Two such tools were recently posted to SearchWinComputing, Unstoppable Copier (gui) and Bad Block Copy (cli). There are other tools, but I’ve mentioned them elsewhere on here before (and recently too!). I’m sure there are other forensics tools that do this sort of stuff very nicely, but are likely cost-prohibitive for home users.

ICMP can be blocked or allowed, or one can instead allow the good stuff and block the unnecessary stuff. This paper should give the quick details on which is which. Gleaned from Shane Castle on the Security Catalyst forums.