Always beware of conference wireless...

ZDNet UK is running an article about some attackers providing counterfeit wireless access to attendees. According to the story, the crackers strolled around the conference with access points running on their laptops and advertising well-known SSIDs (like tmobile). When a victim associated with the access point, the software generated
randomly-mutated malware (to bypass antivirus scanners) and attempted to download it onto the client.

None of these features are new, but the combination is. This is a very nasty (and probably quite effective) use of existing off-the-shelf technology.

Schneier on "Hacking the Papal Election"

This is how you think about everything in your life if you're in the security field. Check out Bruce Schneier's analysis on Hacking the Papal Election.

Insight on this month's "Scan of the Month"

Richard Bejtlich (analyst, author and blogger extraordinaire) has a good point in his latest blog entry. The Honeynet Project's Scan of the Month collects a whole lot of data, but how much time will it take a good analyst to complete the challenge? Properly applied NSM certainly would make this sort of thing much easier. Go sguil!

DoD goes l33t

Wired News is running an article, titled U.S. Military's Elite Hacker Crew, about the Joint Functional Component Command for Network Warfare (JFCCNW). Although everyone has pretty much assumed that our military has had this Information Warfare capability for some time, the existence of l33t gov't h4x0rs has recently been confirmed. Not much other detail is available, but this is a start.

Five Mistakes of Incident Response

InfosecWriters has a short but sweet paper by Anton Chuvakin, entitled Five Mistakes of Incident Response. It's a quick, easy read that I wholeheartedly recommend. In fact, I would have added a mistake #0: Panicking. Keeping your cool is always the most important thing in Incident Response. Still, this paper is a great summary of the other top five mistakes to avoid.

Detecting attacks in RFC3514-compliant traffic

Those of you who run RFC3514-compliant networks might be interested in this snort rule I wrote. It has an unusually good detection rate, with very low false positive and false negative rates. So far it's working well for me, so I thought I'd share it:

alert ip any any -> any any (msg:"RFC 3514 Attack Traffic Detected"; fragbits:R; classtype:misc-attack; sid:35140; rev:1;)