Security Incidents mailing list archives
Re: cuebot-d infection method
From: Jayson Anderson <sonick () sonick com>
Date: Sat, 27 Aug 2005 09:12:38 -0700
Greetings Harlan, I apologize for not getting back to you sooner. Left early and went camping in Sedona, had to get away for a bit ;) When I made the comment in regards to checking for potential punch-through incidents in the ip filters and firewalls between the host in question and the world, I'm referring to not just the host itself, but any network device in the path that may have information on the incident; some of it direct such as an IDS spotting an atypical packet(s), some of it indirect such as a UNIX kernel or application message buried in a *.debug logfile. Someone mentioned netflow, that is an outstanding suggestion as well that i hadn't even considered as i've not needed to yet, but have added that to my own docs as well. Anything in the flow or even each and every broadcast domain along any path such a frame could have possibly traversed (let your mind free, if it's connected L1, it's worth checking). Essentially, and I apologize for being vague; but my suggestion is that to play investigator for such an incident would be to search not just for network anomalies though that is a focal point, but to comb EVERYTHING with potential interrelation from L1-L7, on every single device with an extremely liberal timeframe within which to check. There would almost always be records suggesting enumeration of the network from the outside prior to such a compromise. Personally, I like to configure a dumb host with the TX leads snipped and statically arped via the other machines and a meticulously maintained /etc/hosts file, that just sits there with a huge disk and snarfs the absolute highest granularity of [udp] logging facility possible from every single net-related device in the DMZ' and the first 1-2 tiers beyond. In my experience, all the fancy high-dollar reporting in the world can't replace a per-pop single logfile upon which you can run regex after regex, or even just stare at each and every entry from the timeframe in question, until you find that one entry that gives you the clue or lead that you need. On hosts that perform edge routing or edge services, I turn up the debugging levels as much as possible without hurting performance, then direct all of that to the dumb syslog box for later perusal. Even raw netflow can go there, everything you can think of......... So yeah, my suggestion is basically check everything with potential clues, L1-L7, bar none with a generous timeframe until it does or doesn't flesh out something worth checking. Examples are going to be an NDA issue but let me have a route through my prior engagements and see what I can come up with (will send off-list..) Best Regards, Jayson - On Sat, 2005-08-27 at 02:19 -0700, Harlan Carvey wrote:
Jeff, Thanks for the response. However, it doesn't address the comment that Jayson made, re: post-mortem analysis. I'd still really like to know where to look, and what to look for... Thanks. --- Jeff Bryner <jbryner1 () yahoo com> wrote:<harlan & jayson on where to look for post-mortem packet traces> Lacking full network packet logs, one thing I did during this one was look at flow data from our network infrastructure. <disclaimer>my flowdata knowledge is limited</disclaimer> This can be misleading, however because internal flow data will capture the outgoing attack packets that may get blocked later by a firewall. There also doesn't seem to be a one to one correspondence between the flow and what the firewall blocked outgoing. (i.e., the firewall records more blocks than the flow data shows ). Does someone with more flow-data/flow-tools experience know why this may be so? Jeff. P.S. Flow-tools example queries:http://www.splintered.net/sw/flow-tools/docs/flow-tools-examples.html------------------------------------------ Harlan Carvey, CISSP "Windows Forensics and Incident Recovery" http://www.windows-ir.com http://windowsir.blogspot.com ------------------------------------------
Current thread:
- cuebot-d infection method Jeff Bryner (Aug 24)
- RE: cuebot-d infection method Matthew Neeley (Aug 24)
- Re: cuebot-d infection method Matt Stockdale (Aug 24)
- Re: cuebot-d infection method Irwan Ismail (Aug 25)
- RE: cuebot-d infection method Jason Burton (Aug 25)
- Re: cuebot-d infection method Jayson Anderson (Aug 25)
- Re: cuebot-d infection method Harlan Carvey (Aug 26)
- Re: cuebot-d infection method Jeff Bryner (Aug 29)
- Re: cuebot-d infection method Harlan Carvey (Aug 29)
- Re: cuebot-d infection method Jayson Anderson (Aug 29)
- Re: cuebot-d infection method Jose Nazario (Aug 29)
- Re: cuebot-d infection method Irwan Ismail (Aug 25)
- Re: cuebot-d infection method Jeff Bryner (Aug 25)
- Re: cuebot-d infection method Simon Borduas (Aug 29)