Security Breach in AD! Help!

[Guest]

Hello, my name is Todd and I am an MCP (almost an MCSA-2003) working for a
Computer Consulting business. One of our clients (our biggest one) has AD
running and we have had a heck of a time figuring out this problem:
The only 2 people with administrative permissions on the entire domain is
my boss (owner of company) and myself. However, we keep finding new users
that are being created and are being assigned to the built in administrators
group, giving them admin permissions. There appears to be no way to stop
them. We have changed our Administrator account psw (although I don't think
this would have helped anyway as the accounts that are being created have
admin rights...they don't need our account). We have removed all spyware /
adware and have run virus scans galore (although we periodically still have
to remove them from the system...even in the past couple of weeks). The only
ports open are those we are using...it seems to be a secure environment with
the exception of the ghost administrator running around. We have tried
deleting the accounts from the default admin group and have disabled the
accounts. They either reappear after being deleted in a few days or when we
disable the accounts they return with different names like "1" "2" "skip0"
and "dick".

Has anyone ever heard of a similar problem or hack that we could look for
that would allow someone without admin rights (or by using a system account
with those rights) to create admin accounts?

I know this is a complicated one, but this has been going on for over 2
months and we need help!

Thanks in advance

Todd

 

[Steven L Umbach]

For the domain check the membership of the administrators group, the domain
admins, and enterprise admins groups. Make sure it is what it is supposed to
be and if there are any non default groups as members of these groups
evaluate why they are there and check their memberships. Reset the passwords
on every user account [ including yours and your bosses] in any of those
groups. Make sure you are using hard to guess passwords. Also enable
auditing of account logon for success and failure and account management for
success and failure in Domain Controller Security Policy. Auditing of
account management will tell you if group membership has been changed [by
normal means] and by who. You can also look and see when any user has logged
onto the domain and from what computer. Be sure to increase the size of your
security logs quite a bit to sat at least 10mb. You can use the filter view
in Event Viewer or Event Comb to narrow searches.

Check all of your GPO's at the domain and domain controller level to see if
"restricted groups" is configured in a way that could cause such a problem
and also check for any GPO that can apply to domain controllers and Local
Security Policy of each for any startup scripts that may be used to add
accounts to admins/domain admins admins group. Gpresult /v on the domain
controllers can help you do such. Also check Scheduled Tasks and the AT
command on each domain controller for anything unusual. If you are using a
domain account that is in the administrators/domain admins group for any
service authentication in the domain, that accounts passwords is easily
recovered from any domain computer using that account, so check out that as
a possibility.

Your domain controller must be physically secured to some degree or someone
could obtain passwords from them. If nothing else a sturdy locking case that
blocks access to the drives must be used. Configure the cmos of your domain
controllers to boot only from the system drive and password protect the cmos
settings. Also disable USB on the domain controllers in cmos if not needed.
Another possibility is that your passwords are being captured by keyboard
loggers installed on computers that you use. These can be hardware plugged
into the back of the computer keyboard port or in the keyboard cable, or
installed as software. Some programs such as Pest Patrol do a pretty good
job of checking for software keyboard loggers. The Microsoft Spyware program
will check for many also. Be VERY careful on what computers you use domain
admin credentials on. Spy cameras are another way to try and capture user
credentials. Note that telnet connections may be in clear text and ftp
connections will be in clear text so be careful when you use admin
credentials.

I would also examine the domain controllers very carefully and do full
malware scans with at least two different products. Trend Micro has the free
Sysclean package which I would use also along with it's matching pattern
file. Use the free tools from SysInternals - TCPView, Autoruns, and Process
Explorer to examine port usage and process usage on your domain controllers.
Be extremely suspicious of any remote control software, processes that map
to an executable that does not have a publisher name associated with it, and
any process that is not related to anything that should be running on the
domain controller [which can be hard to do if you do not have a known clean
like install to compare to]. Check for root kits by using Plist from
SysInternals to compare the processes running locally to those when you
check processes running from a remote computer. Also run the Microsoft
Baseline Security Analyzer on your domain controllers to check for basic
vulnerabilities including unneeded services and missing critical updates.
That should give you a start. The links below should help. --- Steve

http://www.sysinternals.com/ntw2k/freeware/procexp.shtml -- Link to
SysInterals Process Explorer and other utilities.
http://www.trendmicro.com/download/dcs.asp
http://www.trendmicro.com/download/pattern.asp
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
http://www.microsoft.com/athome/security/spyware/software/default.mspx
http://www.microsoft.com/technet/security/bestprac/bpent/sec3/monito.mspx

 

[Roger Abell]

If this has been going on for a couple months, I would suggest that
you consider that the forest is no longer yours. Finding all and any
things that might be running as System can be virtually impossible,
and there may be codes in place by now such that it is trivial for
a normal account to effect elevation.

You said that only the ports you use are open. But how do you
know that is actually so?

As a test, one could isolate the entire system from the internet,
such that the only people accessing the system in any way must
be logging into an internal machine. Then, remove those accounts
and wait. If they do not appear it is a pretty safe bet that what you
think is a port restriction is not what you think. Consider: you
want port 80 open inbound and out - but did you know it is possible
to plant a software layer that gets first crack at what travels in on
the port, decides if it is a special message for it, and if not passes
it on as if it was not there ?

 

[Guest]

Hello Steven,
Thanks for responding to my post...I was impressed with the length of time
you must have spent to assist me and that means a lot to me.

In response to your reply, I had already verified the correct members were
in the admin groups that should be there...that is actually how this breach
was located after finding other users in the built in admin group that
weren't supposed to be there
..
I have set up auditing of account logon and account management, but since we
have yet to see the audit logs after an account is created i assume the ghost
admin is deleting the trail in the logs...nice huh?

Since my post I have configured Restricted Groups on the domain. I think
this would be invaluble if it were not for the refresh time on the group
policy as I think the default is 90 minutes, and I have tested it and I am
still allowed to create a user and add the user to the built in admin group
without problems. I assume I could log in as that user and do a lot of
damage before the GPO takes effect, unfortunately. If I am wrong about this
then please correct me.

I also checked for startup scripts (good idea, i hadn't thought of that)
....but found none.

As far as physical security goes, the servers are all located in a
datacenter with tons of security including a fingerprint scan and multiple
combo doors someone would have to get through before having access. I also
recently converted the entire set of servers to a rack and found nothing
foreign connected to them that shouldn't be there.

I mentioned in the original post that we had done a lot of virus scanning
and I have used both the trend micro free scan as well as the enterprise
edition of their product. I have also used the panda active scan which
generally catches things that trend micro misses and have removed anything
out of place. I have recently removed about 20 viruses from our SQL server
which is also a domain controller, but the problem we've been having has been
here longer than those viruses have, so I can't give them credit.

I have removed spyware using Spybot Search and Destroy and Ad-aware SE,
although I had never seen that microsoft had the beta out and I have
downloaded that to give it a try, if nothing else another tool to fight
spyware is appreciated.

I ran MBSA and found only some users with domain user permissions had weak
passwords, but all security updates have been applied.

With this additional information...any other ideas? (other than nuke and
pave?)


Thanks again for your time,

Todd

For the domain check the membership of the administrators group, the domain
admins, and enterprise admins groups. Make sure it is what it is supposed to
be and if there are any non default groups as members of these groups
evaluate why they are there and check their memberships. Reset the passwords
on every user account [ including yours and your bosses] in any of those
groups. Make sure you are using hard to guess passwords. Also enable
auditing of account logon for success and failure and account management for
success and failure in Domain Controller Security Policy. Auditing of
account management will tell you if group membership has been changed [by
normal means] and by who. You can also look and see when any user has logged
onto the domain and from what computer. Be sure to increase the size of your
security logs quite a bit to sat at least 10mb. You can use the filter view
in Event Viewer or Event Comb to narrow searches.

Check all of your GPO's at the domain and domain controller level to see if
"restricted groups" is configured in a way that could cause such a problem
and also check for any GPO that can apply to domain controllers and Local
Security Policy of each for any startup scripts that may be used to add
accounts to admins/domain admins admins group. Gpresult /v on the domain
controllers can help you do such. Also check Scheduled Tasks and the AT
command on each domain controller for anything unusual. If you are using a
domain account that is in the administrators/domain admins group for any
service authentication in the domain, that accounts passwords is easily
recovered from any domain computer using that account, so check out that as
a possibility.

Your domain controller must be physically secured to some degree or someone
could obtain passwords from them. If nothing else a sturdy locking case that
blocks access to the drives must be used. Configure the cmos of your domain
controllers to boot only from the system drive and password protect the cmos
settings. Also disable USB on the domain controllers in cmos if not needed.
Another possibility is that your passwords are being captured by keyboard
loggers installed on computers that you use. These can be hardware plugged
into the back of the computer keyboard port or in the keyboard cable, or
installed as software. Some programs such as Pest Patrol do a pretty good
job of checking for software keyboard loggers. The Microsoft Spyware program
will check for many also. Be VERY careful on what computers you use domain
admin credentials on. Spy cameras are another way to try and capture user
credentials. Note that telnet connections may be in clear text and ftp
connections will be in clear text so be careful when you use admin
credentials.

I would also examine the domain controllers very carefully and do full
malware scans with at least two different products. Trend Micro has the free
Sysclean package which I would use also along with it's matching pattern
file. Use the free tools from SysInternals - TCPView, Autoruns, and Process
Explorer to examine port usage and process usage on your domain controllers.
Be extremely suspicious of any remote control software, processes that map
to an executable that does not have a publisher name associated with it, and
any process that is not related to anything that should be running on the
domain controller [which can be hard to do if you do not have a known clean
like install to compare to]. Check for root kits by using Plist from
SysInternals to compare the processes running locally to those when you
check processes running from a remote computer. Also run the Microsoft
Baseline Security Analyzer on your domain controllers to check for basic
vulnerabilities including unneeded services and missing critical updates.
That should give you a start. The links below should help. --- Steve

http://www.sysinternals.com/ntw2k/freeware/procexp.shtml -- Link to
SysInterals Process Explorer and other utilities.
http://www.trendmicro.com/download/dcs.asp
http://www.trendmicro.com/download/pattern.asp
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
http://www.microsoft.com/athome/security/spyware/software/default.mspx
http://www.microsoft.com/technet/security/bestprac/bpent/sec3/monito.mspx

Hello, my name is Todd and I am an MCP (almost an MCSA-2003) working for a
Computer Consulting business. One of our clients (our biggest one) has AD
running and we have had a heck of a time figuring out this problem:
The only 2 people with administrative permissions on the entire domain
is
my boss (owner of company) and myself. However, we keep finding new users
that are being created and are being assigned to the built in
administrators
group, giving them admin permissions. There appears to be no way to stop
them. We have changed our Administrator account psw (although I don't
think
this would have helped anyway as the accounts that are being created have
admin rights...they don't need our account). We have removed all spyware
/
adware and have run virus scans galore (although we periodically still
have
to remove them from the system...even in the past couple of weeks). The
only
ports open are those we are using...it seems to be a secure environment
with
the exception of the ghost administrator running around. We have tried
deleting the accounts from the default admin group and have disabled the
accounts. They either reappear after being deleted in a few days or when
we
disable the accounts they return with different names like "1" "2" "skip0"
and "dick".

Has anyone ever heard of a similar problem or hack that we could look for
that would allow someone without admin rights (or by using a system
account
with those rights) to create admin accounts?

I know this is a complicated one, but this has been going on for over 2
months and we need help!

Thanks in advance

Todd

 

[Ray]

Are you sure you're not being hit from the outside or via a remote
access/modem connection?

How is the security on the enterprise admin account?

Ray

 

[Guest]

I have a question regarding Restricted Groups...

I am trying to make the changes that I've set for Restricted Groups to be as
close to real time as possible. We had another user created today and in
about 5 minutes the user was removed from the built in admin group. I have
changed the default domain policy, the default domain controller policy, and
the local machine policy all to reflect the following changes trying to make
this a real time restriction:
I have enabled the... refresh interval for computers to 0, refresh interval
for domain controllers to 0 for the computer policies
as well as the refresh interval for users to 0 for the user policies.
I obviously do not know what I am doing since I don't know what Group policy
to apply and on what interface to get my desired results.

Please help!

thanks

Todd

For the domain check the membership of the administrators group, the domain
admins, and enterprise admins groups. Make sure it is what it is supposed to
be and if there are any non default groups as members of these groups
evaluate why they are there and check their memberships. Reset the passwords
on every user account [ including yours and your bosses] in any of those
groups. Make sure you are using hard to guess passwords. Also enable
auditing of account logon for success and failure and account management for
success and failure in Domain Controller Security Policy. Auditing of
account management will tell you if group membership has been changed [by
normal means] and by who. You can also look and see when any user has logged
onto the domain and from what computer. Be sure to increase the size of your
security logs quite a bit to sat at least 10mb. You can use the filter view
in Event Viewer or Event Comb to narrow searches.

Check all of your GPO's at the domain and domain controller level to see if
"restricted groups" is configured in a way that could cause such a problem
and also check for any GPO that can apply to domain controllers and Local
Security Policy of each for any startup scripts that may be used to add
accounts to admins/domain admins admins group. Gpresult /v on the domain
controllers can help you do such. Also check Scheduled Tasks and the AT
command on each domain controller for anything unusual. If you are using a
domain account that is in the administrators/domain admins group for any
service authentication in the domain, that accounts passwords is easily
recovered from any domain computer using that account, so check out that as
a possibility.

Your domain controller must be physically secured to some degree or someone
could obtain passwords from them. If nothing else a sturdy locking case that
blocks access to the drives must be used. Configure the cmos of your domain
controllers to boot only from the system drive and password protect the cmos
settings. Also disable USB on the domain controllers in cmos if not needed.
Another possibility is that your passwords are being captured by keyboard
loggers installed on computers that you use. These can be hardware plugged
into the back of the computer keyboard port or in the keyboard cable, or
installed as software. Some programs such as Pest Patrol do a pretty good
job of checking for software keyboard loggers. The Microsoft Spyware program
will check for many also. Be VERY careful on what computers you use domain
admin credentials on. Spy cameras are another way to try and capture user
credentials. Note that telnet connections may be in clear text and ftp
connections will be in clear text so be careful when you use admin
credentials.

I would also examine the domain controllers very carefully and do full
malware scans with at least two different products. Trend Micro has the free
Sysclean package which I would use also along with it's matching pattern
file. Use the free tools from SysInternals - TCPView, Autoruns, and Process
Explorer to examine port usage and process usage on your domain controllers.
Be extremely suspicious of any remote control software, processes that map
to an executable that does not have a publisher name associated with it, and
any process that is not related to anything that should be running on the
domain controller [which can be hard to do if you do not have a known clean
like install to compare to]. Check for root kits by using Plist from
SysInternals to compare the processes running locally to those when you
check processes running from a remote computer. Also run the Microsoft
Baseline Security Analyzer on your domain controllers to check for basic
vulnerabilities including unneeded services and missing critical updates.
That should give you a start. The links below should help. --- Steve

http://www.sysinternals.com/ntw2k/freeware/procexp.shtml -- Link to
SysInterals Process Explorer and other utilities.
http://www.trendmicro.com/download/dcs.asp
http://www.trendmicro.com/download/pattern.asp
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
http://www.microsoft.com/athome/security/spyware/software/default.mspx
http://www.microsoft.com/technet/security/bestprac/bpent/sec3/monito.mspx

Hello, my name is Todd and I am an MCP (almost an MCSA-2003) working for a
Computer Consulting business. One of our clients (our biggest one) has AD
running and we have had a heck of a time figuring out this problem:
The only 2 people with administrative permissions on the entire domain
is
my boss (owner of company) and myself. However, we keep finding new users
that are being created and are being assigned to the built in
administrators
group, giving them admin permissions. There appears to be no way to stop
them. We have changed our Administrator account psw (although I don't
think
this would have helped anyway as the accounts that are being created have
admin rights...they don't need our account). We have removed all spyware
/
adware and have run virus scans galore (although we periodically still
have
to remove them from the system...even in the past couple of weeks). The
only
ports open are those we are using...it seems to be a secure environment
with
the exception of the ghost administrator running around. We have tried
deleting the accounts from the default admin group and have disabled the
accounts. They either reappear after being deleted in a few days or when
we
disable the accounts they return with different names like "1" "2" "skip0"
and "dick".

Has anyone ever heard of a similar problem or hack that we could look for
that would allow someone without admin rights (or by using a system
account
with those rights) to create admin accounts?

I know this is a complicated one, but this has been going on for over 2
months and we need help!

Thanks in advance

Todd

 

[Steven L Umbach]

As far as Restricted Groups, double check that you have it configured
correctly by checking the membership of the groups you are restricting.
Since it is applying to domain controllers, if done right, the refresh time
should be five minutes. You can test that out by adding a non authorized
test user to the restricted group and seeing how long it takes for it to
disappear. The time interval can be shortened more if need be in Group
Policy. That still may give the attacker enough time to do what he wants,
and he may just disable or reconfigure Restricted Groups so keep an eye on
that though it still makes sense to configure restricted groups.

It is great that your ran all of those scans, but be sure to check for Root
Kits on your domain controllers by checking processes as I suggested.
Normally a Root Kit will NOT be detected by a host virus scan. See the links
below about Root Kits and a tool that may help. The fact that your domain
controller has already been infected is a problem in that you can not be
confident that it is clean without a reinstall.

http://www.securityfocus.com/news/2879
http://www.security.nnov.ru/search/document.asp?docid=6198 --- where to
get RKdetect.
http://www.microsoft.com/technet/community/columns/secmgmt/sm0504.mspx --
one opinion on compromised systems.

That is a problem if the security logs are being deleted. Note that the
entry for the time the log was cleared may be a clue in itself and that you
can check the accounts that this attacker creates by checking it's "object"
properties in AD Users and Computers for the time the account was created.
You may be interested in a logging analysis tool from Languard that can do
centralized backups and issue email alerts on certain Event ID's. I have not
used it myself but others seem to like it and you can try if for 30 days for
no charge as shown in the link below.

http://www.gfi.com/lanselm/ -- Languard logging program.

The attacker is somehow obtaining your passwords OR he owns one of the
domain controllers [at least]. I would also check Domain Controller Security
Policy for user rights to make sure they are correct and you can use the
Security Configuration and Analysis tool mmc snapin to analyze against the
setup security.inf template which you should do on the domain controllers
for user rights and security options to see what differs from default. I
assume you changed your passwords recently which is a must. Keep in mind
that all domain admins must follow best practices with their domain admins
accounts such as never user the same password for ANYTHING else such as
another domain account or local computer account, always logoff or lock your
computer when not at it, NEVER used stored/saved admin credentials for
Internet Explorer, mapped drives, applications, XP stored credentials, etc.,
avoid ever using domain admin credentials on a Windows 95/98 computer are
they use weak lm hash. Domain admin credentials should not be used to manage
domain computers - create a regular domain user account that is added to the
local administrator group of domain computers which can easily be done with
a Group Policy startup script and use that account to manage domain
computers. Domain admin credentials should only be used when needed to
manage the domain and even a lot of those tasks can be delegated. I guess my
point is that if not careful there are a lot of places that an attacker can
get domain admin credentials or use domain admin credentials such as if a
domain admin walks away from a computer while still logged on as a domain
admin. You might want to consider smart cards for domain admin access and
configure the accounts to only be able to logon via smart card and have
smart card readers at the computers that you use to manage the domain. You
can not do that however with the built in administrator account but you
could give that account a very long password and never use it. Anyhow I hope
you make some headway. --- Steve

http://www.lokbox.net/SecureXP/secAnalysis.asp -- Security Configuration
and Analysis tool.

Hello Steven,
Thanks for responding to my post...I was impressed with the length of time
you must have spent to assist me and that means a lot to me.

In response to your reply, I had already verified the correct members were
in the admin groups that should be there...that is actually how this
breach
was located after finding other users in the built in admin group that
weren't supposed to be there
.
I have set up auditing of account logon and account management, but since
we
have yet to see the audit logs after an account is created i assume the
ghost
admin is deleting the trail in the logs...nice huh?

Since my post I have configured Restricted Groups on the domain. I think
this would be invaluble if it were not for the refresh time on the group
policy as I think the default is 90 minutes, and I have tested it and I am
still allowed to create a user and add the user to the built in admin
group
without problems. I assume I could log in as that user and do a lot of
damage before the GPO takes effect, unfortunately. If I am wrong about
this
then please correct me.

I also checked for startup scripts (good idea, i hadn't thought of that)
...but found none.

As far as physical security goes, the servers are all located in a
datacenter with tons of security including a fingerprint scan and multiple
combo doors someone would have to get through before having access. I
also
recently converted the entire set of servers to a rack and found nothing
foreign connected to them that shouldn't be there.

I mentioned in the original post that we had done a lot of virus scanning
and I have used both the trend micro free scan as well as the enterprise
edition of their product. I have also used the panda active scan which
generally catches things that trend micro misses and have removed anything
out of place. I have recently removed about 20 viruses from our SQL
server
which is also a domain controller, but the problem we've been having has
been
here longer than those viruses have, so I can't give them credit.

I have removed spyware using Spybot Search and Destroy and Ad-aware SE,
although I had never seen that microsoft had the beta out and I have
downloaded that to give it a try, if nothing else another tool to fight
spyware is appreciated.

I ran MBSA and found only some users with domain user permissions had weak
passwords, but all security updates have been applied.

With this additional information...any other ideas? (other than nuke and
pave?)


Thanks again for your time,

Todd

For the domain check the membership of the administrators group, the
domain
admins, and enterprise admins groups. Make sure it is what it is supposed
to
be and if there are any non default groups as members of these groups
evaluate why they are there and check their memberships. Reset the
passwords
on every user account [ including yours and your bosses] in any of those
groups. Make sure you are using hard to guess passwords. Also enable
auditing of account logon for success and failure and account management
for
success and failure in Domain Controller Security Policy. Auditing of
account management will tell you if group membership has been changed [by
normal means] and by who. You can also look and see when any user has
logged
onto the domain and from what computer. Be sure to increase the size of
your
security logs quite a bit to sat at least 10mb. You can use the filter
view
in Event Viewer or Event Comb to narrow searches.

Check all of your GPO's at the domain and domain controller level to see
if
"restricted groups" is configured in a way that could cause such a
problem
and also check for any GPO that can apply to domain controllers and Local
Security Policy of each for any startup scripts that may be used to add
accounts to admins/domain admins admins group. Gpresult /v on the domain
controllers can help you do such. Also check Scheduled Tasks and the AT
command on each domain controller for anything unusual. If you are using
a
domain account that is in the administrators/domain admins group for any
service authentication in the domain, that accounts passwords is easily
recovered from any domain computer using that account, so check out that
as
a possibility.

Your domain controller must be physically secured to some degree or
someone
could obtain passwords from them. If nothing else a sturdy locking case
that
blocks access to the drives must be used. Configure the cmos of your
domain
controllers to boot only from the system drive and password protect the
cmos
settings. Also disable USB on the domain controllers in cmos if not
needed.
Another possibility is that your passwords are being captured by keyboard
loggers installed on computers that you use. These can be hardware
plugged
into the back of the computer keyboard port or in the keyboard cable, or
installed as software. Some programs such as Pest Patrol do a pretty good
job of checking for software keyboard loggers. The Microsoft Spyware
program
will check for many also. Be VERY careful on what computers you use
domain
admin credentials on. Spy cameras are another way to try and capture user
credentials. Note that telnet connections may be in clear text and ftp
connections will be in clear text so be careful when you use admin
credentials.

I would also examine the domain controllers very carefully and do full
malware scans with at least two different products. Trend Micro has the
free
Sysclean package which I would use also along with it's matching pattern
file. Use the free tools from SysInternals - TCPView, Autoruns, and
Process
Explorer to examine port usage and process usage on your domain
controllers.
Be extremely suspicious of any remote control software, processes that
map
to an executable that does not have a publisher name associated with it,
and
any process that is not related to anything that should be running on the
domain controller [which can be hard to do if you do not have a known
clean
like install to compare to]. Check for root kits by using Plist from
SysInternals to compare the processes running locally to those when you
check processes running from a remote computer. Also run the Microsoft
Baseline Security Analyzer on your domain controllers to check for basic
vulnerabilities including unneeded services and missing critical updates.
That should give you a start. The links below should help. --- Steve

http://www.sysinternals.com/ntw2k/freeware/procexp.shtml -- Link to
SysInterals Process Explorer and other utilities.
http://www.trendmicro.com/download/dcs.asp
http://www.trendmicro.com/download/pattern.asp
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
http://www.microsoft.com/athome/security/spyware/software/default.mspx
http://www.microsoft.com/technet/security/bestprac/bpent/sec3/monito.mspx

Hello, my name is Todd and I am an MCP (almost an MCSA-2003) working
for a
Computer Consulting business. One of our clients (our biggest one) has
AD
running and we have had a heck of a time figuring out this problem:
The only 2 people with administrative permissions on the entire
domain
is
my boss (owner of company) and myself. However, we keep finding new
users
that are being created and are being assigned to the built in
administrators
group, giving them admin permissions. There appears to be no way to
stop
them. We have changed our Administrator account psw (although I don't
think
this would have helped anyway as the accounts that are being created
have
admin rights...they don't need our account). We have removed all
spyware
/
adware and have run virus scans galore (although we periodically still
have
to remove them from the system...even in the past couple of weeks).
The
only
ports open are those we are using...it seems to be a secure environment
with
the exception of the ghost administrator running around. We have tried
deleting the accounts from the default admin group and have disabled
the
accounts. They either reappear after being deleted in a few days or
when
we
disable the accounts they return with different names like "1" "2"
"skip0"
and "dick".

Has anyone ever heard of a similar problem or hack that we could look
for
that would allow someone without admin rights (or by using a system
account
with those rights) to create admin accounts?

I know this is a complicated one, but this has been going on for over 2
months and we need help!

Thanks in advance

Todd

 

[Roger Abell [MVP]]

see reply in your new thread . . .
it is computer policy
--
Roger

I have a question regarding Restricted Groups...

I am trying to make the changes that I've set for Restricted Groups to be
as
close to real time as possible. We had another user created today and in
about 5 minutes the user was removed from the built in admin group. I
have
changed the default domain policy, the default domain controller policy,
and
the local machine policy all to reflect the following changes trying to
make
this a real time restriction:
I have enabled the... refresh interval for computers to 0, refresh
interval
for domain controllers to 0 for the computer policies
as well as the refresh interval for users to 0 for the user policies.
I obviously do not know what I am doing since I don't know what Group
policy
to apply and on what interface to get my desired results.

Please help!

thanks

Todd

For the domain check the membership of the administrators group, the
domain
admins, and enterprise admins groups. Make sure it is what it is supposed
to
be and if there are any non default groups as members of these groups
evaluate why they are there and check their memberships. Reset the
passwords
on every user account [ including yours and your bosses] in any of those
groups. Make sure you are using hard to guess passwords. Also enable
auditing of account logon for success and failure and account management
for
success and failure in Domain Controller Security Policy. Auditing of
account management will tell you if group membership has been changed [by
normal means] and by who. You can also look and see when any user has
logged
onto the domain and from what computer. Be sure to increase the size of
your
security logs quite a bit to sat at least 10mb. You can use the filter
view
in Event Viewer or Event Comb to narrow searches.

Check all of your GPO's at the domain and domain controller level to see
if
"restricted groups" is configured in a way that could cause such a
problem
and also check for any GPO that can apply to domain controllers and Local
Security Policy of each for any startup scripts that may be used to add
accounts to admins/domain admins admins group. Gpresult /v on the domain
controllers can help you do such. Also check Scheduled Tasks and the AT
command on each domain controller for anything unusual. If you are using
a
domain account that is in the administrators/domain admins group for any
service authentication in the domain, that accounts passwords is easily
recovered from any domain computer using that account, so check out that
as
a possibility.

Your domain controller must be physically secured to some degree or
someone
could obtain passwords from them. If nothing else a sturdy locking case
that
blocks access to the drives must be used. Configure the cmos of your
domain
controllers to boot only from the system drive and password protect the
cmos
settings. Also disable USB on the domain controllers in cmos if not
needed.
Another possibility is that your passwords are being captured by keyboard
loggers installed on computers that you use. These can be hardware
plugged
into the back of the computer keyboard port or in the keyboard cable, or
installed as software. Some programs such as Pest Patrol do a pretty good
job of checking for software keyboard loggers. The Microsoft Spyware
program
will check for many also. Be VERY careful on what computers you use
domain
admin credentials on. Spy cameras are another way to try and capture user
credentials. Note that telnet connections may be in clear text and ftp
connections will be in clear text so be careful when you use admin
credentials.

I would also examine the domain controllers very carefully and do full
malware scans with at least two different products. Trend Micro has the
free
Sysclean package which I would use also along with it's matching pattern
file. Use the free tools from SysInternals - TCPView, Autoruns, and
Process
Explorer to examine port usage and process usage on your domain
controllers.
Be extremely suspicious of any remote control software, processes that
map
to an executable that does not have a publisher name associated with it,
and
any process that is not related to anything that should be running on the
domain controller [which can be hard to do if you do not have a known
clean
like install to compare to]. Check for root kits by using Plist from
SysInternals to compare the processes running locally to those when you
check processes running from a remote computer. Also run the Microsoft
Baseline Security Analyzer on your domain controllers to check for basic
vulnerabilities including unneeded services and missing critical updates.
That should give you a start. The links below should help. --- Steve

http://www.sysinternals.com/ntw2k/freeware/procexp.shtml -- Link to
SysInterals Process Explorer and other utilities.
http://www.trendmicro.com/download/dcs.asp
http://www.trendmicro.com/download/pattern.asp
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
http://www.microsoft.com/athome/security/spyware/software/default.mspx
http://www.microsoft.com/technet/security/bestprac/bpent/sec3/monito.mspx

Hello, my name is Todd and I am an MCP (almost an MCSA-2003) working
for a
Computer Consulting business. One of our clients (our biggest one) has
AD
running and we have had a heck of a time figuring out this problem:
The only 2 people with administrative permissions on the entire
domain
is
my boss (owner of company) and myself. However, we keep finding new
users
that are being created and are being assigned to the built in
administrators
group, giving them admin permissions. There appears to be no way to
stop
them. We have changed our Administrator account psw (although I don't
think
this would have helped anyway as the accounts that are being created
have
admin rights...they don't need our account). We have removed all
spyware
/
adware and have run virus scans galore (although we periodically still
have
to remove them from the system...even in the past couple of weeks).
The
only
ports open are those we are using...it seems to be a secure environment
with
the exception of the ghost administrator running around. We have tried
deleting the accounts from the default admin group and have disabled
the
accounts. They either reappear after being deleted in a few days or
when
we
disable the accounts they return with different names like "1" "2"
"skip0"
and "dick".

Has anyone ever heard of a similar problem or hack that we could look
for
that would allow someone without admin rights (or by using a system
account
with those rights) to create admin accounts?

I know this is a complicated one, but this has been going on for over 2
months and we need help!

Thanks in advance

Todd

 

[Guest]

Thanks for your help Steven.

I found the solution to the group policy refresh interval thing...sort of.

I went to computer configuration, administrative templates, system, group
policy...
Then I changed the Group Policy refresh interval for computers and the Group
Policy refresh interval for domain controllers both to 0.
Then I enabled Scripts policy processing and marked the box next to "process
even if the group policy objects have not changed"
This was done in both the local security policy as well as the default
domain controllers policy.

This has set my GPO's to refresh about every 7 seconds at most. This was
the temporary solution I was trying to obtain.

I am looking further into the root kit stuff...that may also help us find a
solution.
For now, I think with your help (and others) we believe we have at least put
a dent in the problem and can focus our attention less on getting rid of
ghost admins and more on getting rid of the script or hack that caused it in
the first place. If anyone reads this post and knows what could be causing
this please post a reply to assist us. Even if the problem is long gone, I
would like to know how they did it for next time.

Thanks again for your help!

Todd

 

[Steven L Umbach]

OK. Todd. Let us know how it goes.

I can not emphasize the importance of being very careful using domain
credentials on computers that you are not 100 percent sure of being secured
both physically and for the operating system and use runas as much as
possible.. I would examine very carefully any computers that you use them on
regularly and personally do a fresh install. Keep in mind that any scripts
or commands run while you are logged on as a domain admin run in the context
of that account.

For example suppose an attacker knew that a domain admin used a particular
computer to logon as domain admin [any account with admin powers in the
domain]. If that computer was left unattended for a period of time while
logged on or the attacker could get physical access to in order to
compromise it he could put a simple script such as a logon script or logoff
script on it via local Group Policy [gpedit.msc]. That script could use the
net user /domain and net group /domain commands to create a user account and
add it to the domain admins/administrators group every time the legitimate
user logged on or off with a domain admin account without ever knowing the
password for the domain admin account and would still work after the domain
admin changed his password! Such a script could never be found with a virus
scan.

An attacker could also use social engineering to trick a domain admin to
logon to a domain computer with that account with a similar script on the
domain computer which the attacker had been able to easily get local admin
access via a free utility downloadable from the internet assuming the
attacker could boot the computer from floppy, cdrom, or other external drive
means. A good attacker would not do this on his computer, but do it to some
"favorite" person of the admins computer and muck it up just enough to
warrant him coming over to logon to it to see what the problem is as the
damsel in distress puts out the call. Anyhow do not rule out the option that
your attack maybe coming from a computer on the network where domain admin
credentials are used to logon/logoff. -- Steve

 

[Gordon Fecyk]

I have set up auditing of account logon and account management, but since
we

have yet to see the audit logs after an account is created i assume the ghost
admin is deleting the trail in the logs...nice huh?

If this is the case, you should at least see "Security log has been cleared"
in the security event log. Is there some other way to "erase" entries in a
security event log without leaving an audit trail?

I assume I could log in as that user and do a lot of
damage before the GPO takes effect, unfortunately. If I am wrong about this
then please correct me.

Isn't it possible to force GPO replication with a command line?

<http://support.microsoft.com/default.aspx?scid=kb;en-us;227448>

 

[Guest]

I had a post earlyer regarding using windows as a server, and the website
admin deleted-it.
I said that a server is supposed to be a server, not a user-friendly
enviroment, full of bugs and back-doors, and i suggested using a
unix/bsd/linux os.
For the fact that my post was deleted, i will stop using windows in any way,
i will move to linux, and change the whole infrastructure of my work place to
linux, that's about 100 computers.
I sugest that more people do this, to force Microsoft to be less monopolistic.

 

[Roger Abell [MVP]]

calm down now . . .

From what you have said of its content your post would not have
been purged due to what it said.

There was a "burp" a week or so ago, in which I noticed three
parts of threads went absent / were purged which I had been
participant in and which were not purge candidates

In general, posts only seem to get purged if
- they are blatant advertisment or spam
- they are offensive in commonly accepted senses (vulgar)
- they may constitute slander or liable

Anyway, enjoy your Unix derived 100 PC environment.