Re: A Hack Attack and IPC$

From: David (davidwnh_at_adelphia.net)
Date: 08/09/03 

Date: Sat, 09 Aug 2003 20:38:01 GMT

The IPC$ "share" is critical for NetBios. It is not like a file share, but
allows interprocess communication between machines.It will be gone if you
disable NetBios, but whether you can do this without breaking anything
depends on whether the specific machine relies on any NetBios network
functionality.In any case you may be concentrating on a solution that is
totally inappropriate for what you need internally. They did not gain entry
via the IPC$ share, they were simply using the functionality it provides to
possibly further compromise your network. In most cases Windows networks are
still reliant on NetBios. Unless you are dealing with a standalone server,
you would need a Win2K+ AD domain using only TCP/IP functionality to cut
this reliance, however some of their other servers(SMS etc.) and
services(Network Browser Service etc.) still rely on NetBios also. It is
used for not only for file sharing but also for remote administration. If
you have 135,137,139, and 445 blocked at the firewall NetBios is
inaccessible from outside. This would have also prevented the initial
exploit experienced in this case. A hacker can still use TCP/IP based
tools/trojans remotely to control NetBios based tools within the LAN,
however if your LAN needs NetBios for some of its functionality than so be
it. You should change the appropriate registry setting to disallow
nonexplicitly defined anonymous connections. If you are dealing with a
standalone server that doesn't need NetBios, simply get rid of NetBios.
Otherwise it needs to be blocked with a firewall. In any case they can
accomplish the same from within with TCP/IP based tools so you better
concentrate on keeping them out in the first place.

It looks like they put both a remote admin server and an ftp server on the
machine to start with so you better take a really good look at this machine.
They could have downloaded any file off of the machine....including the SAM
database.
Chances are they uploaded a password cracker and were running it from the
compromised machine and not remotely.
>
>
> My basic question: I know there is a way to delete the IPC$ share
> during a session but is there a way to delete the share so it does not
> create on reboot?
>
> We learned enough about the hack, removed the offending pieces,
> applied SP4, set up our own little watchdog and spied on the server
> for several days. The hackers had copied a few files to the server:
> winsql.exe, sql.exe, winsystem.exe, and some other supporting files.
> winsql.exe was a Trojan. It was a renamed serv-u ftp exe which was
> enabled as a service. winsystem.exe, another Trojan, was a copy of our
> "no-longer-used" remote admin program radmin.exe.
>

If this was not a "kiddie", they might have run the same RPC exploit from
the compromised machine directed at the domain controller or any other
machines on the LAN. Maybe they did but ran a password cracker to blow smoke
up your *** and make you think otherwise?
> So what's wrong with that, it would be next millennium until he
> figured out any of the passwords? Well, for one, you don't' want
> someone banging on your backdoor 24 hours a day, even though your
> passwords are intense, they might get lucky. Second, and most
> important, since all the user accounts on the server were locked, even
> the admin and other mission critical accounts, my own server would
> deny even *my* access. I guess the hacker's logic was, "If I (the
> hacker) can't get in then neither will the server admin. heh,heh." He
> was right.
>

Quantcast