A Hack Attack and IPC$

From: John Cesta (support_at_serverautomationtools.com)
Date: 08/09/03 

Date: Sat, 09 Aug 2003 14:07:39 -0400

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?

Read the following if you need to know why this is important.

Also, I hope this never happens to you.

On M$ systems there are administrative shares that are created
automatically. Some of these admin shares include: C$, D$, ADMIN$ and
most importantly, IPC$ (a remote share).

A client, recently, was one of the lucky (hmmphh) ones picked out and
hacked via the RPC vulnerability

 M$ KB Article and fix: Buffer Overrun In RPC Interface Could Allow
Code Execution (823980).

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.

They used the following little script to do the dirty work:

<start hack script>
ren r_server.exe winsystem.exe
regedit -s radmin.reg
winsystem /install /silence
sc config "r_server" displayname= Windrivers
del radmin.reg
net start r_server
</end hack script>

A few legitimate programs like sc.exe, an M$ resource kit tool to
create a service, psexec.exe, a tool from sysinternals.com and a few
others were also included in the mix. Our AV software caught some of
these, some it didn't.

We checked ports and ran all the virus cleaning tools many times. Now
satisfied that we cleaned house and rid the server of the stuff the
bad guys left behind.

During our "learning" we found a tool from foundstone.com that scans
an IP and lists things from the probed server.

What "things" does it list? Users, groups, shares, user
characteristics such as the password lockout policy and other
"trivial" stuff that M$ is so willing to provide. What does this
program probe I thought? An associate found the probe-ee to be an
administrative share called IPC$. Sure enough, delete this share and
the information is no longer provided.

A few days later I noticed that some of the Win2k user accounts were
locked. I unchecked the "locked out" box and rebooted. Everything was
fine. Within moments the accounts were locked once again. I clicked on
the local security policy icon and, under the auditing policies,
turned on auditing for logon events and a few others. I then looked in
the Event viewer's security tab and sure enough the hacker was
pounding away on the server trying to gain passwords. I realized that
this character must have probed the server, probably using the same
method I discovered, got the user names (the one ahead principle) and
started a password party.

The fact the "login lockout" setting was set to “1 failed login equals
a 30-minute wait” did not deter this joker. The hits just kept comin'.

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.

I remember what my associate said about the IPC$ being the subject of
the probe. I wondered if it was also true for the method this hacker
was using to beat me up. One way to find out....I removed the IPC$
share and the hackers hacks came to an abrupt halt.

Now, the question becomes, what happens when the server reboots? Since
the IPC$ share re-creates on server reboots this could be a problem.
I'm ok now I thought, but when the server reboots, and the bad guy
starts knocking again (starts his automated password detector), even I
won't be able to open the door (gain access to the server).

The temporary solution: Create a batch file that deletes the IPC$
share, run the bat file in the task scheduler every minute. That
should take care of any reboot problems.

The point of this story is two-fold:

First, to educate others (maybe) from my experience. Maybe I have
provided some solutions if it happens to you. Second, to query the
Win2k Server users and administrators to find a solution to the admin
share IPC$ being a dangerous means of entry to our servers.

Is there anyway to prevent this probe?

Is there any way to remove the IPC$ share permanently? Or, is there a
way to lockout access to the share. I noticed there isn't a way to set
permissions on the share.

John Cesta

Relevant Pages

  • Re: The server is not configured for transactions
    ... To follow up on what Michael said, you can see if the IPC$ share exists by ... uninstalling and reinstalling the File and Print Sharing network service. ... That should re-create and share out properly the IPC$ share. ... >> I am running it as a proxy server and a PDC. ...
    (comp.os.ms-windows.nt.admin.security)
  • Admin$ and IPC$ shares disappear repeatedly
    ... one DC is now having a problem where the Admin$ and IPC$ shares disappear ... I can type "net share admin$" ... The same happens with IPC$. ... promote another server to be a DC. ...
    (microsoft.public.win2000.general)
  • Re: Admin$ and IPC$ shares disappear repeatedly
    ... scanner at pandasoftware.com which I've found is very good. ... then you'll need to reapply service packs and updates as your server ... > admin$ is no longer listed. ... The same happens with IPC$. ...
    (microsoft.public.win2000.general)
  • Re: Passing MarshalByRef object to Remoted Server
    ... If I understand you, what you are trying to do it get the client to use IPC to talk to the server, which is using TCP? ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Server not configured for transactions
    ... Use "net share" command on the shared computer to check share status. ... there is not a share named "IPC$" in the share list, ... Make sure WINS and DNS are running on the server. ... > back to the Microsoft Windows Network folder looking at ...
    (microsoft.public.win2000.setup_deployment)
Loading