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
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
Facebook
Twitter
Instagram