Re: cuebot-d infection method

• Previous message: matt: "Re: cuebot-d infection method"
• Maybe in reply to: Jeff Bryner: "cuebot-d infection method"
• Next in thread: Jose Nazario: "Re: cuebot-d infection method"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: incidents@securityfocus.com, Harlan Carvey <keydet89@yahoo.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
> ------------------------------------------

• Previous message: matt: "Re: cuebot-d infection method"
• Maybe in reply to: Jeff Bryner: "cuebot-d infection method"
• Next in thread: Jose Nazario: "Re: cuebot-d infection method"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]