Server 2003 AD brute force attacked from other server

Seems like the failed attempts are like classic known weakness of kerberos systems.
- Replay attacks and password-guessing attacks. A replay attack would involve intercepting or otherwise acquiring a Kerberos ticket and then fraudulently representing that ticket in an attempt to gain authentication. Password guessing in a Kerberos system could be done by intercepting Kerberos tickets from the network and then making a brute force attempt to decrypt the intercepted tickets.
-  An attacker may exploit outdated software in the infrastructure. For example, there are many problems with Kerberos version 4. In order to prevent these attacks, Kerberos 5 has been modified to use triple DES in Cipher Block Chaining (CBC) mode.
- Having said that password attack in v5 based on password is still possible (like in this case).

Recommendations (ref to http://www.windowsdevcenter.com/pub/a/windows/excerpt/swarrior_ch14/index1.html):
a) Authentication scheme that relies on only username and password can be cracked using repeated attempts. This is why most password protected resources will limit the number of unsuccessful login attempts over a time period to a reasonably low number that still guarantees a typo won't lock the user out forever.

b) For increased security extra services will be required such as limiting login attempts (or better yet hiding the server from all but) a known trusted range of network addresses (either logical addresses such as IP ranges or stronger still physical addresses like MAC addresses or other hardware specific data, possibly a combination of all these).

c) By using both hardware authentication combined with allowing only known network addresses AND username/password authentication you can at least be sure that any attempt comes from inside the known network AND from a known machine on that network. If you have people using l0phtcrack on the internal LAN it should then be easy to catch them by logging the number of repeated fail attempts from a single connection and having some alarm trigged to security if there's an unusual number of fails from a given location (say more than 5 attempts in a 10 minute interval to the same account, or attempting to log into 5 accounts in that same interval).

d) Adding smartcards into the equation makes it even easier to pinpoint the source of the intrusion attempt. But this is a more tedious change over especially having higher cost due to hardware involved but do consider it for longer term

>> As of now I suggest changing the password lockdown attempts (reactive to contain attack for interim) and if possible up a backup server (see below) for failover (business continuity).

High resiliency related info:
a) Kerberos was designed to allow for a Master/Slave replication cluster. While a Kerberos cluster can consist of any number of hosts, it is recommended that you have at least two. A master which serves as the primary server and at least one slave which is available as a backup to the master. The master and slave servers may be thought of as Primary and Secondary servers respectively.

b) Despite the errors, do also note that critical system (like AD) should maintain high availability and scalability. Take a look at You should be looking at "Using IT Procedures to Increase Availability and Scalability" in <http://technet.microsoft.com/en-us/library/cc786570(WS.10).aspx>

For AD (or kerberos systems), do spend some time looking at the practices:
a) Automated clustering - http://technet.microsoft.com/en-us/library/cc787869(WS.10).aspx
b) Deploying secure AD - http://technet.microsoft.com/en-us/library/cc756081(WS.10).aspx
c) Strengthening Domain and Domain Controller Policy Settings (see audit and password portion) - http://technet.microsoft.com/en-us/library/cc773142(WS.10).aspx
http://tldp.org/HOWTO/Kerberos-Infrastructure-HOWTO/server-replication.html

Hope it helps

Agree that the DC should be "restore" into original state.
You may also want to consider Virtual image for DC and restoring is easier (reverting snapshots).
Minimally AV need to be installed but note that it should not be connected online (preferably not), hence manual update is needed.
Better to have some IDS or HIPS in the infrastructure so that these similar traffic can be monitored and alerts can be correlated early (but revamp take times and consideration, talk to the IT Team)

Also to share that beside Virustotal, you can consider online malware analysis services like ThreatExpert, CwSandbox. They give more detail reports (check out their sample reports) as VirusTotal is more of a "surface report"
- http://www.threatexpert.com/introduction.aspx
- http://www.cwsandbox.org/?site=1&page=submit

Last but not least, do harden your server and turn off unnecessary services e.g. Telnet, etc. Good to go for pentest as regular checks

Firstly, if that box is that important that you cannot shut it down, invest in redundancy.

Secondly, you (almost) definately have a rootkit, because rootkits setup a .sys file to mask their true apps. Look for exe's in the Windows and windows\system32 directory with the Hidden and Read on or system attribute and approach any with suspicion.