[Dshield] [SPAM] Re: Network shut down by old pc
www.whitewolf at gmail.com
Sat Aug 12 23:29:39 GMT 2006
Again, I'm not familiar enough with your network to come up with a
definitive answer, but I'm not entirely convinced any MAC spoofing did in
fact occur given what information has been provided. In fact, I completely
overlooked that possibility in my last response. You said the root level
switch had no entry for that MAC, but that's not entirely unheard of,
especially with out me knowing the layout of your network. Do any of the
other devices have a record of that MAC? How complete is that cached info
(how large of a time span does it cover and are you sure that the PC in
question was turned on and connected to the network at the time)? Are there
any devices between that PC and the root level switch and if so, what types
and have you checked their logs? Most importantly, given the cached info
from that root level switch, by process of elimination, can you determine
what the MAC address should be for the PC in question?
Of course, it would be a mistake to rule out malicious code/activities all
together, but more than once I have found myself eager to shout attack, only
to later eat my own words when I found some minute detail that I had
overlooked. I like to rule out any other explanations before settling with
my initial response. If you can find a record showing that that PC was
supposed to have a different MAC than the one it has now, then yes, without
a doubt that PCs MAC has been spoofed and the next step I would suggest is
to run over that computer with a fine-toothed comb to search for the
malicious code or any evidence left behind by a malicious individual to
determine just what all has been done to that computer, and possibly the
rest of your network. Otherwise, for now I will choose to error on the side
of caution and say I believe that for some reason the PCs MAC address just
didn't get populated into that particular switch's cache (maybe it was
turned off at the time) and the MAC Address is indeed as it should be.
My main reasoning behind this is that most of the time, when an attacker
spoofs a MAC, it is to match a known MAC on the network to avoid MAC
filtering. I see no logical reason for an attacker to spoof the MAC of a
known system to an unknown MAC unless it was just to avoid conflicts between
the spoofed and spoofing systems, which shouldn't be an issue. With that in
mind, have you checked your logs since you removed the 98 PC from your
network to see if there is any additional traffic appearing to be coming
from the PC in question? At this point, I doubt you would find any, but if
so it would support your theory of malicious activities and warrant more of
an investigation into who/what is behind this incident.
Given how finicky Win 98 can be, especially when it comes to networking, I'm
going to speculate this this all could have been one of those times where
all it takes is a good reboot of the 98 box and things would be back to
normal, but if you're right, I highly recommend digging deeper as this could
be only the tip of the iceberg. I look forward to a response to see if
anything I have said pointed any fingers in the right directions to lock
down the actual cause and move beyond speculations.
P. S. Please forgive the rambling nature of this email. I tend to do that
a lot when brainstorming...
On 8/11/06, Mikel Williams <mikelw at ruffinbuildingsystems.com> wrote:
> I had considered the possibility that a foreign DHCP server, such as a DSL
> router from home, had been installed into the network.
> However, that still would not account for the spoofed MAC address from the
> pc. I would be more ready to dismiss it as a "glitch" if it weren't for
> that spoofed MAC, which wasn't just a corrupted MAC. It was a validly
> formatted address, which identified the unit as a Cameo device commonly
> in network switches. That to me indicates an attempt to hide the source
> the offending traffic, and in my thinking is what makes it appear more as
> malicious activity of some sort as opposed to just a corrupted IP stack.
> Thanks for the response,
> ----- Original Message -----
> From: "John Dietz" <www.whitewolf at gmail.com>
> To: "General DShield Discussion List" <list at lists.dshield.org>
> Sent: Friday, August 11, 2006 7:42 AM
> Subject: [SPAM] Re: [Dshield] Network shut down by old pc
> > Of course I could be wrong, but it sounds to me like either the server
> > hosting the DHCP pool had a glitch (or was poisoned) and stopped
> > the 192.168.0.1 IP or another computer was serving DHCP at the time and
> > didn't have the rule to exclude 192.168.0.1 from the pool. Do you maybe
> > have a BDC that could have decided to take over these requests after
> > loosing
> > communication with the PDC? Of course, without packet logs and without
> > knowing your network better, it would be hard to know for sure just what
> > happened, but this is at least my theory. Since you said all the
> > configurations on the Win 98 box are as they should be, I doubt it is
> > victim of malicious code installed on it. It sounds a lot more like a
> > DHCP
> > issue to me.
> > Cheers
> > On 8/10/06, Mikel Williams <mikelw at ruffinbuildingsystems.com> wrote:
> >> Looking for info on possible cause of the following scenario:
> >> Small business network with primary domain controller, file server, and
> >> DHCP
> >> services provided by a
> >> Win NT 4.0 server, SP 6A, configured as follows;
> >> IP address of 192.168.0.1 (NIC's MAC address of
> >> Providing services for the domain of DHCP, WINS, Primary DNS,
> >> basic
> >> file storage, and printer shares
> >> Most pc's running Win2K or Win XP, except for 2 older boxes still
> >> Win98.
> >> (These 2 older boxes have been in the network for upwards of 10
> >> with no problems)
> >> Internet access across network is restricted to selected stations that
> >> get
> >> gateway address and expanded DNS server list
> >> by DHCP reservation and gateway access control list on
> >> firewall/router.
> >> Here's the problem;
> >> Late yesterday afternoon domain users began having problems hitting
> >> network
> >> printers, all shared from Primary Domain Controller.
> >> Subsequent checks showed that none of them could hit the server at
> >> all,
> >> but other network connection remained intact.
> >> Server event log revealed loss of network connection due to an IP
> >> conflict, with a station having MAC address of 00:C0:F0:12:EB:58
> >> (Same MAC address also resolved using ARP from a backup server
> >> following
> >> ping of 192.168.0.1)
> >> Check of cached info from root level switch for the network finds no
> >> entry
> >> for the offending MAC.
> >> Process of elimination by using perpetual ping from various stations as
> >> network branches and cables are unplugged lead
> >> to one of the old Win98 boxes, which has been running with no
> >> for years.
> >> (Offending PC immediately isolated from network pending further
> >> investigation)
> >> (Policies in effect on the pc prevented even myself from being able
> >> get to the network configuration)
> >> This AM, after using policy editor to recover the system, all network
> >> configuration is as it was before;
> >> IP address by DHCP
> >> Since no DHCP server is available during isolation from network,
> >> Windows used auto-generated IP address of 169.254.158.91
> >> The real kicker, is that the MAC address of the offending NIC is
> >> 00:C0:F0:12:EB:58
> >> I have no plans to re-introduce the renegade system into the network,
> >> it's due for a replacement anyway.
> >> I am still wanting to find out what happened here, especially since it
> >> has
> >> the appearance of orginating from some form of malicious code.
> >> Have any of you experienced this issue, or know of any eploits which
> >> would
> >> have this effect.
> >> The end result was a crash of the primary domain server, but the false
> >> MAC
> >> address is equally disturbing.
> >> Thanks for any info,
> >> Mike Williams
> >> _________________________________________
> >> Learn from the founder of DShield how to secure your Internet presence
> >> with Linux, Apache, MySQL, PHP.
> >> Las Vegas, Oct. 2nd-6th 2006
> >> Details: http://www.sans.org/ns2006/description.php?tid=433
> >> (Brochure Code: ISC)
> >> _______________________________________________
> >> send all posts to list at lists.dshield.org
> >> To change your subscription options (or unsubscribe), see:
> >> http://lists.dshield.org/mailman/listinfo/list
> > --
> > There is intelligence is in having all the answers, but wisdom lies in
> > knowing which of the questions to answer.
> > _________________________________________
> > Learn from the founder of DShield how to secure your Internet presence
> > with Linux, Apache, MySQL, PHP.
> > Las Vegas, Oct. 2nd-6th 2006
> > Details: http://www.sans.org/ns2006/description.php?tid=433
> > (Brochure Code: ISC)
> > _______________________________________________
> > send all posts to list at lists.dshield.org
> > To change your subscription options (or unsubscribe), see:
> > http://lists.dshield.org/mailman/listinfo/list
> Learn from the founder of DShield how to secure your Internet presence
> with Linux, Apache, MySQL, PHP.
> Las Vegas, Oct. 2nd-6th 2006
> Details: http://www.sans.org/ns2006/description.php?tid=433
> (Brochure Code: ISC)
> send all posts to list at lists.dshield.org
> To change your subscription options (or unsubscribe), see:
There is intelligence is in having all the answers, but wisdom lies in
knowing which of the questions to answer.
More information about the list