1:00 AM
El DiPablo
This will be my second to last post on the topic of, “Oh sweet baby Jesus! My client got his Domain Controller Hacked!” If you haven’t been following my posts for the last few days, a local business man and I sort of barter for services. I fix his computers and he gives me and my family free stuff. Well, a few days ago it turned out that his Domain Controller got rooted. Nice!
So far in this series I’ve mentioned how I was able to reset the Domain Admin password because the attacker changed it. I talked about how I think the attacker got in, and what I did to fix that. Now I’m going to talk about something else I found on this server. Backdoor accounts!
Never heard of a backdoor account? Here is a clip from the movie Tron Legacy as an example of how a backdoor account can be used:
So you get the idea right? Basically according to Wikipedia a Backdoor is:
…a method of bypassing normal authentication, securing remote access to a computer, obtaining access to plaintext, and so on, while attempting to remain undetected. The backdoor may take the form of an installed program (e.g., Back Orifice) or may subvert the system through a rootkit.
Or in this case, new accounts with higher level access than they should. Along with newly created accounts, they also changed some built-in accounts. Once account was called something like SUPPORT_3746578e0. If you ever look into the built in accounts for some Windows operating systems, this account is is used for Microsoft Support to fix your machine for you. By default this account should be in the HelpServicesGroup only. The other account they messed with was Guest. By default this account should only be a member of the Guests group.
Well this hacker went ahead and put the above accounts in the Built-In Administrators group as well as the Domain Administrators groups. He also created a couple of other rather legit looking accounts, and added them to those same groups. He probably did this so if one of his accounts got discovered, he could get in with another. Good idea.
I went ahead and deleted the ones they created, but for the built-in accounts if you delete them, they will come back at reboot. So for them I renamed them and changed their passwords to a ridiculously long random password, removed them from the above groups, and set their login hours to denied. I also created a fake Guest account with a similar ridiculously long password and no access as well. I also went through all the groups with administrative access and removed any suspicious accounts that had no business being there.
After a reboot for something else I was working on, I found that the hacker had put something in place that restored Administrator access to the built-in accounts of Guest and SUPPORT_3746578e0. Pretty slick if you asked me. This time it was the fake Guest account that had the access though, that’s how I knew something was amiss!
I checked in all the usual places for startup scripts, but couldn’t find where that guy put it. For that I just had to fight his Kung Fu with some Tiger Crane, and write my own startup script that deleted those accounts at startup, and checked for them every so often and if found delete them. Kind of a pain in the arse if you ask me!
On top of my script I also created a group policy that restricted the members of the Domain Admins group and the Built-in Administrators group to just the user accounts that needed to be there.
I am fairly certain I got all the backdoors, and cut off the attacker’s access. Still though, after you’ve been compromised you can’t be too sure. That is why I have been actively monitoring the security logs vigilantly, and will continue to do so for the foreseeable future.
Got any other suggestions? Places to look for that damned startup script? Anything you would do differently? Let me know in the comments.
