All I can say is you should Nuke the smeggar to oblivion. ONe swift knee in the happy sacks and it'll drop like anyone else.
 
Then restore from backup.
Otherwise go throught all the users permisisons and delegations and hope for the best (if security isn't a big issue that is)

It would really depend on what the hacker did to the system. If it was via registry permissions or simple policy mods, you could counteract this by reapplying whatever policy you were using (assuming you maintained offline copies of it) on the DC and in the domain. If registry key permissions were used, they would be corrected when the template was applied (at least, in theory). I use imaging software to backup my servers, so I can rollback to any point and have a fully functional system. This would be ideal, but I am getting the impression that you do not have any reliable (or complete) backup system in place. In addition, if the hacker used an application on the system that had a vulnerability (such as an FTP or VPN service), you might still have a large hole to deal with anyway.
 
The ideal (and proper) use of DCs in a domain would include having redundant DCs (with GCs, except for the IM FSMO holder) that are *not* on the perimeter (on the Internet, hosting VPN connections, etc to reduce services that could be compromised and reduce direct contact) and behind a firewall. I am under the impression that the DC may have been acting as a webserver, which would make it much easier to attack. In theory, if you had another DC that you could use to host the GC for your domain, and then move the FSMO roles over, it could work. You would have to reapply all templates to your domain (again, assuming this was the method of modification used) before adding any new systems, and validate the integrity of all current member systems in the domain.

Thanks for the responses duhmez and clutch.
 
I liked duhmez's solution best
 
Unfortunately you're right clutch. I didn't have a proper back up system in place. I just purchased a tape library system for this exact reason and was planning to implement it during the holidays (which is, as we all know, the only time administrators get to catch up on any work).
 
As for back-up polices, I had back-ups and I did reapply them to no avail.
 
I haven't tried reapplying the reg key templates yet though.
 
Is there any instruction on how to go about reapplying those templates as I am not familiar with that process.
 
I will probably end up building from scratch again any way to clear any doubts.
 
Btw, I do not run any of the IIS services or third party web services and I am protected by a nice strong firewall from the outside. The only thing that my network has fault with is that the internal LAN setup has not been segmented yet between labs and servers as of yet. So as long as you have access to one of the units inside, you can pretty much hack your way to the servers.
 
Thanks in advance all.

That sucks. The use of templates for regkey and file permissions management is rarely used, and with good reason. For those people that have been using NSA-based templates in 2000 and migrating to 2003, you will appreciate what I mean. The "SERVICE" account in 2000 has been broken up into a couple accounts, and these restrictive policies with NTFS permissions have broken things such as the winreg key access and the like in new installs of 2003. In addition, if a regkey was modified by someone and then a template was reapplied, the key permissions will *not* be adjusted unless the template specifies that key in particular with permissions. In other words, like most template functions that are left "Not Defined" in a policy manual changes will not be changed nor reset.
 
A complete tear down is the best way to address this. In the future, using image-based backup applications (like PowerQuest V2i or Ghost) is the best way to assure system integrity with immediate restoration.