Intrusion on Windows server 2003 Advanced Mass Sender

For port 80, do you have any website or web application?

Does it use SQL Server as a database?

Maybe they hacked via SQL injection (google it - lots of information).

Thanks for the prompt answer

The web-application only use static access-databases, but Sql-server is installed for Backup Exec, that's the only App using SQL.

Trying to do this after the fact is tricky... SQL injection is possible - but with RDP port open to the world, a simple brute-force attack is also a possible candidate.

What do you want to do here? If you want to find out who did it, you may well be disappointed unless it was an "insider"; if you just want to prevent it happening again you will find plenty of suggestions here!

Remember that if you want to investigate, you don't want to delete or change anything on the system, for example knowing what time the rogue accounts were created gives a timeframe.

Thanks,

Hi Hapexamendios
Thanks for Your reply.
I know the Time-interval (20/3 between 00:00 and 00:16 AM. It was when the admins were created. The App was installed around 06:00AM).

I guess I miss a Link to "... suggestions here".

Thanks in Advance

Ah - by "suggestions here" I mean on this site :)

I guess you want to investigate, then? I can understand that.

Before we start, be advised that it's possible you'll now realise some forms of logging required to back-track here are not enabled. If that is the case you'll need to put it down to experience, enable the needed logging - and then if it happens again you shoudl be in a better position.

First off, are there any "success" audits for logons to the server just prior to the creation of these accounts? If so, we will try to use the tool "eventcombNT.exe" (from Microsoft) to establish the source IP address that logon came from. As such, back up your Event Logs now to make sure they don't get overwritten.
(Information on where the connection originated might also appear in your firewall logs, if you can cross-reference the time - but this depends on where the illicit connection came from, and whether the connection would have passed through your firewall.)

If there are no "Success" audit logs, there can be two causes: auditing odf logon events is not enabled OR the attack involved exploiting an existing logon such as the SYSTEM account, meaning no new logon would be generated.

To check if auditing is enabled, go to Start >> Run and type "rsop.msc", then hit Enter. You'll get the Resultant Set of Policy for the computer.
Expand Computer Configuration>>Windows Settings>>Security Settings>>Local Policies>>Audit Policy
Look at what is enabled for "Audit account logon events" and "Audit logon events". If the values are not to your liking, you'll need to determine which of your domain's Group Policy Objects you would like to change this setting in. (I'd suggest the "Default Domain Controllers" policy if you have a small uncomplicated domain, but this is a decision for yourself really.)

For the purpose of what we're doing here, you would want "Success" and "Failure" both ticked, for both "...account logon" and "...logon..." events. Remember that to do this, you'll need to increase the default size of your Security Event Log. I suggest changing the size using the same Group Policy Object as for enabling auditing. Mine are set to 100 MB in some cases, because of the amount of events. This is to make sure you can actually track back for a reasonable amount of time in the event of such incidents.

There's much more, but to save overloading you with superfluous steps, could you verify whetehr you can see any events for a suspicious logon prior to rogue account creation, and let me know?

Thanks

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.