Hacker Breach!!! - Event 515: A trusted logon process has registered with the Local Security Authority
One of my servers was breached by a member of a discharged IT company.
The security logs has the remote log-on listed, but the IP I traced to a proxy in Texas (we are in Chicago) so there is no proving this.
The intruder got in using the old BESAdmin service - password was never changed - and from there was able to give himself privileges enough to get into AD and make password changes to the Admin account (this is not the Administrator account but a 2nd "Admin" account we use to allow the office manager some admin rights.)
My worry is that among the security logs, in-between the unauthorized log-on and their retreat - was this:
"Event Type: Success Audit
Event Source: Security
Event Category: System Event
Event ID: 515
Date: 10/10/2007
Time: 10:31:00 PM
User: NT AUTHORITY\SYSTEM
Computer: SERVER
Description:
A trusted logon process has registered with the Local Security Authority. This logon process will be trusted to submit logon requests.
Logon Process Name: Winlogon\MSGina
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."
Now, has the "hacker" set up another means of authentication to my server?
Again, all passwords have been changed again, including those on the BESAdmin. The ports and passwords for VNC access have been changed and the 2 accounts belonging to Enterprise Admin and Domain admin are secure.
But how about this Event 515 and "A trusted logon process has registered with the Local Security Authority" addition I seem to have now?
How do I lock this thing down?
**Also, the reason the hacker left was it seems he accidentally tripped the Windows Update Service icon and the server rebooted after the updates were installed. If the server had not rebooted we would never have know he was there (the SQL Express service never starts on its own after a re-boot and it causes a world of hurt for BB users, so the phone started ringing early this morning)
Then he/she never came back. But the logs don't lie. And the password for "Admin" was definitely altered at 10:43pm (2 minutes before the update re-boot) - perhaps so they could return.
The security logs has the remote log-on listed, but the IP I traced to a proxy in Texas (we are in Chicago) so there is no proving this.
The intruder got in using the old BESAdmin service - password was never changed - and from there was able to give himself privileges enough to get into AD and make password changes to the Admin account (this is not the Administrator account but a 2nd "Admin" account we use to allow the office manager some admin rights.)
My worry is that among the security logs, in-between the unauthorized log-on and their retreat - was this:
"Event Type: Success Audit
Event Source: Security
Event Category: System Event
Event ID: 515
Date: 10/10/2007
Time: 10:31:00 PM
User: NT AUTHORITY\SYSTEM
Computer: SERVER
Description:
A trusted logon process has registered with the Local Security Authority. This logon process will be trusted to submit logon requests.
Logon Process Name: Winlogon\MSGina
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."
Now, has the "hacker" set up another means of authentication to my server?
Again, all passwords have been changed again, including those on the BESAdmin. The ports and passwords for VNC access have been changed and the 2 accounts belonging to Enterprise Admin and Domain admin are secure.
But how about this Event 515 and "A trusted logon process has registered with the Local Security Authority" addition I seem to have now?
How do I lock this thing down?
**Also, the reason the hacker left was it seems he accidentally tripped the Windows Update Service icon and the server rebooted after the updates were installed. If the server had not rebooted we would never have know he was there (the SQL Express service never starts on its own after a re-boot and it causes a world of hurt for BB users, so the phone started ringing early this morning)
Then he/she never came back. But the logs don't lie. And the password for "Admin" was definitely altered at 10:43pm (2 minutes before the update re-boot) - perhaps so they could return.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Phil_Agcaoili
3101 is the BES port.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I image this server once a month. What I was realy concerned about was this:
My worry is that among the security logs, in-between the unauthorized log-on and their retreat - was this:
"Event Type: Success Audit
Event Source: Security
Event Category: System Event
Event ID: 515
Date: 10/10/2007
Time: 10:31:00 PM
User: NT AUTHORITY\SYSTEM
Computer: SERVER
Description:
A trusted logon process has registered with the Local Security Authority. This logon process will be trusted to submit logon requests.
Logon Process Name: Winlogon\MSGina
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."
Now, has the "hacker" set up another means of authentication to my server?"
There have been no further breaches after all passwords and ports for remote access were changed. The BES port has been fine and left alone.
Thanks for the input.
-MP
My worry is that among the security logs, in-between the unauthorized log-on and their retreat - was this:
"Event Type: Success Audit
Event Source: Security
Event Category: System Event
Event ID: 515
Date: 10/10/2007
Time: 10:31:00 PM
User: NT AUTHORITY\SYSTEM
Computer: SERVER
Description:
A trusted logon process has registered with the Local Security Authority. This logon process will be trusted to submit logon requests.
Logon Process Name: Winlogon\MSGina
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."
Now, has the "hacker" set up another means of authentication to my server?"
There have been no further breaches after all passwords and ports for remote access were changed. The BES port has been fine and left alone.
Thanks for the input.
-MP
When you say "Logon Process Name: Winlogon\MSGina" That process is something that Microsoft uses. MS Gina is the Press CTRL ALT DEL box you get where you enter username and password to login. Then it checks the local SAM (Security Account Manager) #1 does account exist, and #2 does supplied password match verified existing and non-disabled or locked account. After that, you get desktop.
Are there any weird accounts on your server that you did not create?
Are there any weird accounts on your server that you did not create?
ASKER
No. I went painstakingly though all of AD and there is nothing I cannot account for. I also disabled all accounts that were not being used or only used marginaly. Then I made sure that only 2 accounts, the default administrator and mine, has domain admin and enterprise admin privlidges. No one listed in schema admins or part of the power user or remote workplace/access groups that I cannot account for either. AD is locked down tight.
In this case, I would change the passwords for the accounts that have Administrative credentials.
Next, I would enable auditing for Account Logon Failure events. Optionally, you could audit successful attempts, then export the Security Event Log as a text comma delimited CSV file. Open that with Microsoft Excel, Highlight the top row where the column headers are (such as Type, Date, Time, Source, Category, Event etc.) then click on the Data menu, click Filter, then choose Auto Filter.
Now you can filter the list by account and see if there are any anomalies, click on the drop down arrow for the User field, and choose an account. Excel will filter the list and only show events related to that user account. This should help narrow down any unauthorized activity. Pay special attention to events that happen outside normal business hours.
Finally, give this Microsoft site a look at. http://technet2.microsoft.com/windowsserver/en/library/b4145d9a-c4aa-4e0d-b5bc-cb14c7ff69cd1033.mspx?mfr=true
There are some tools for troubleshooting why accounts are being locked out, if you happen to use automated account login via a script or program.
"The ALockout.dll tool and the Appinit.reg script are included in the ALTools package. ALockout.dll is a logging tool that may help you determine the program or process that is sending the incorrect credentials in an account lockout scenario"
Chris
Next, I would enable auditing for Account Logon Failure events. Optionally, you could audit successful attempts, then export the Security Event Log as a text comma delimited CSV file. Open that with Microsoft Excel, Highlight the top row where the column headers are (such as Type, Date, Time, Source, Category, Event etc.) then click on the Data menu, click Filter, then choose Auto Filter.
Now you can filter the list by account and see if there are any anomalies, click on the drop down arrow for the User field, and choose an account. Excel will filter the list and only show events related to that user account. This should help narrow down any unauthorized activity. Pay special attention to events that happen outside normal business hours.
Finally, give this Microsoft site a look at. http://technet2.microsoft.com/windowsserver/en/library/b4145d9a-c4aa-4e0d-b5bc-cb14c7ff69cd1033.mspx?mfr=true
There are some tools for troubleshooting why accounts are being locked out, if you happen to use automated account login via a script or program.
"The ALockout.dll tool and the Appinit.reg script are included in the ALTools package. ALockout.dll is a logging tool that may help you determine the program or process that is sending the incorrect credentials in an account lockout scenario"
Chris