Security Breach in AD! Help!

Archived from groups: microsoft.public.win2000.security (More info?)

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
10 answers Last reply
More about security breach help
  1. Archived from groups: microsoft.public.win2000.security (More info?)

    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

    "Todd" <Todd@discussions.microsoft.com> wrote in message
    news:10C4CF0D-C6FB-4678-AFBC-D8DBDEB97003@microsoft.com...
    > 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
    >
    >
    >
    >
    >
  2. Archived from groups: microsoft.public.win2000.security (More info?)

    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 ?

    --
    Roger Abell
    Microsoft MVP (Windows Security)
    MCSE (W2k3,W2k,Nt4) MCDBA
    "Todd" <Todd@discussions.microsoft.com> wrote in message
    news:10C4CF0D-C6FB-4678-AFBC-D8DBDEB97003@microsoft.com...
    > 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
    >
    >
    >
    >
    >
  3. Archived from groups: microsoft.public.win2000.security (More info?)

    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


    "Steven L Umbach" wrote:

    > 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
    >
    > "Todd" <Todd@discussions.microsoft.com> wrote in message
    > news:10C4CF0D-C6FB-4678-AFBC-D8DBDEB97003@microsoft.com...
    > > 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
    > >
    > >
    > >
    > >
    > >
    >
    >
    >
  4. Archived from groups: microsoft.public.win2000.security (More info?)

    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

    "Todd" <Todd@discussions.microsoft.com> wrote in message
    news:10C4CF0D-C6FB-4678-AFBC-D8DBDEB97003@microsoft.com...
    > 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
    >
    >
    >
    >
    >
  5. Archived from groups: microsoft.public.win2000.security (More info?)

    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


    "Steven L Umbach" wrote:

    > 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
    >
    > "Todd" <Todd@discussions.microsoft.com> wrote in message
    > news:10C4CF0D-C6FB-4678-AFBC-D8DBDEB97003@microsoft.com...
    > > 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
    > >
    > >
    > >
    > >
    > >
    >
    >
    >
  6. Archived from groups: microsoft.public.win2000.security (More info?)

    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.


    "Todd" <Todd@discussions.microsoft.com> wrote in message
    news:2398FCAA-62F6-4D23-B6DA-BE53B283320A@microsoft.com...
    >
    > 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
    >
    >
    >
    > "Steven L Umbach" wrote:
    >
    >> 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
    >>
    >> "Todd" <Todd@discussions.microsoft.com> wrote in message
    >> news:10C4CF0D-C6FB-4678-AFBC-D8DBDEB97003@microsoft.com...
    >> > 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
    >> >
    >> >
    >> >
    >> >
    >> >
    >>
    >>
    >>
  7. Archived from groups: microsoft.public.win2000.security (More info?)

    see reply in your new thread . . .
    it is computer policy
    --
    Roger
    "Todd" <Todd@discussions.microsoft.com> wrote in message
    news:A03DD4A7-7D54-498E-B15E-0751895BD7DE@microsoft.com...
    >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
    >
    >
    > "Steven L Umbach" wrote:
    >
    >> 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
    >>
    >> "Todd" <Todd@discussions.microsoft.com> wrote in message
    >> news:10C4CF0D-C6FB-4678-AFBC-D8DBDEB97003@microsoft.com...
    >> > 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
    >> >
    >> >
    >> >
    >> >
    >> >
    >>
    >>
    >>
  8. Archived from groups: microsoft.public.win2000.security (More info?)

    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
  9. Archived from groups: microsoft.public.win2000.security (More info?)

    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


    "Todd" <Todd@discussions.microsoft.com> wrote in message
    news:216BE3A5-1715-4239-97A8-1B80CDBD92EB@microsoft.com...
    > 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
    >
    >
  10. Archived from groups: microsoft.public.win2000.security (More info?)

    > 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>

    --
    PGP key (0x0AFA039E): <http://www.pan-am.ca/consulting@pan-am.ca.asc>
    Prevent problems before they happen and help others avoid bad design.
    <http://www.pan-am.ca/antiwindowscatalog/>
Ask a new question

Read More

Security Windows