A Hack Attack and IPC$. Watch your backdoor(s)!

An update (Sun 6/27/04) to this article and the solution I found see this article

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 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

If you like this article or maybe had a similar experience and would like to share it with other readers then feel free to:

Simply fill in YOUR e-mail address, your name and your comment. Click the SEND button.

After submitting your comment, you will be transported back to the article you commented on!

	Name	E-Mail Address
You
Sending to
	Your Message

John Cesta is a contract programmer. John's current project is designer and lead developer of the automated hosting software at bestcfhosting.com, a ColdFusion MX hosting company. John is currently working on commercializing his programs and offering them to the IIS community at serverautomationtools.com