Steve's Security Blog | @northvein

Apart from being a source of all too frequent and embarrassing typos, Splunk is a big data platform which allows you to interrogate data and present results is a variety of contexts and visualisations. I've been using it for a little over 12 months, self teaching or Googleing as I go, predominantly to sift through the terabytes of logs from various applications and appliances that get generated in my 9-5 every day.  You can use Splunk to build dashboards which are typically better than the ones that come with the product ( full size )  I've started to pull together all the searches, notes and bits of code into a sort of security cheat sheet which I thought would be a good thing to share as well as providing some real world examples of how you might use Splunk in a security context.  Cheat Sheet I'm actively working back through my notes and adding to this all the time so it might be a good thing to reference via the URL or re-visit from time to time. I'll t

Like so many others I'm seeing an influx of booby-trapped Microsoft Word documents being sent in as email attachments with the end goal of infecting our endpoints with the Feodo/Cridex/Bugat trojan.  I'm relatively new to the whole malware analysis game, but what stands out to me more than the payload is the evidence of a strategy being played out. If you step back and look at the big picture, its clear that this is the work of an adversary that knows what they want, knows how they might achieve that and, most importantly, understands their target and their defenses. If our enemies are our greatest teachers then we, as security professionals, tasked with detecting and responding to threats can learn a lot from them. Not only can we use what we learn to shore up and improve our defenses but we can also use it to highlight, quantify and demystify our enemies to those we are charged with protecting. That last bit is perhaps most important because it is them, the stakehold

I don't think I'd had chance to get my seat warm on Monday when I was approached by our service support function who were getting inundated with details about a 'virus' doing the rounds at via email which, when opened, forwarded itself to everyone in the user's address book. I don't normally get involved with desktop issues but I'm always happy to help and eager to understand risks both technically and from a wider business perspective. It seemed our endpoint anti-virus 'solution' had a 0% first-time detection success rate and by this time it had already managed to sneak past our 3rd party email security gateway. I set about acquiring a copy of the offending payload and decided that it would make a good candidate for a 'blind taste test' to run past a few online sandboxes. If you're not familiar with the concept, sandboxes are controlled environments within which you can run un-trusted programs and capture details about how they behave.

I let the honeypot run for 98 days in total. Looking back, I don't know why I didn't let it run for exactly 100 but I suspect it had something to do with me moving house around that time. I took note of my observations as I shut it down and grepped and awked my way through the logs to produce summary stats. The first observation I recall making was the disparity between the number of connections to the site on the domain name vs. the number of connections to the site on the IP address. You'll find (regrettably) that a lot of websites will still serve you content if you connect on the IP address. It's a good idea to disable this functionality and simply present a generic error. This way, you'll eliminate a lot of your exposure to automated scanning, and the figures below corroborate this: Connections to site via domain vs. via IP address Lets not forget that my honeypot was set up in such a way that, in theory at least, there could be no possible legitimate

Honeypots are currently in vogue with lots of security researchers writing about how they can be used to profile adversaries and detect emerging threats. I ran a Wordpress honeypot last year for little more than three months as a little exercise in setting up, running and then monitoring the results produced by these invaluable security tools. I decided that as a first attempt, I'd use it to attempt to assess the average level of technical capability of those individuals or parties that seek to identify and exploit common web applications. Anyone who reviews the logs of any website, big or small, can tell you that these kinds of attack form a huge percentage of the 'background' noise of the internet. I never really intended to share the details or results of this exercise but I've since changed my mind and hope that if you too have considered setting up and running your own that my 'notes' might encourage you to do so. As soon as I started playing around w

I've always been a fan of OpenDNS. Even before they switched to being a  security outfit, I used them for content filtering in the office and at home. If you're not familiar with their offering I'd recommend visiting their website and taking a look for yourself. OpenDNS.com Earlier this year, a colleague overseas got in touch to let me know he'd put OpenDNS in at a few office locations based in other countries. The good news was that change had been seamless and that OpenDNS had instantly started to spot malicious DNS requests originating from both sites. The bad news was that he had no way or idea of working out which desktops or servers were making the bad requests as he had almost no visibility on those networks and no body on site able to help.  OpenDNS Dashboard Activity Summary Having your public DNS alert you to malicious requests originating from an office or country is a bit like having a smoke alarm on the 40th floor. Sure, it lets