nt4.trojaned.profiles.txt

`Date: Wed, 28 Apr 1999 20:36:58 +0100  
From: Mnemonix <[email protected]>  
To: [email protected]  
Subject: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
  
Problem : NT users can cause other users of the system to load a "trojaned" profile that could lead to a system compromise. This  
issue has been here for as long as NT 4 has, but I'm not sure if anybody has picked this particular issue up.  
  
Details: When a user logs onto an NT Workstation or Server a new subkey is written to the HKLM\Software\Microsoft\Windows  
NT\CurrentVersion\ProfileList registry key. The name of this new key is that of the user's Security Identifier or SID. One of  
the values of this key is the ProfileImagePath which points to the location of the user's profile directory. This can reference  
a local path (eg %systemroot%\profiles\acc_name) or a UNC path (eg \\PDC\profiles\acc_name).   
  
By default, the permissions on the ProfileList registry key grants the Everybody group the SetValue permission meaning that any  
user including guests may edit the information in this subkey and all of its subkeys. Consequently a malicious user of the  
system could change another user's ProfileImagePath and get it to load a different profile (eg c:\trojaned-profile) that  
contains entries in the Start Up folder that will run when that user next logs on to that system.   
  
Editing these Registry keys can be done local or from across the network. Although remote access to the registry can be  
controlled by placing controls on the winreg key, the HKLM\Software\Microsoft\Windows NT\CurrentVersion path into the Registry  
is, by default, an AllowedPath, meaning that, irrespective of the ACLs set on the winreg key, a remote user may edit any subkey  
under the CurrentVersion key. Note that tools such as Regedit.exe and Regedt32.exe will not be able to be used to to this. The  
NT Resource Kit's reg.exe could though because it opens a handle straight to the Registry key in question.  
  
Attack Scenario: This weakness of default settings, could allow a normal domain user to gain domain Administrative rights:  
Assuming the attackers machine is called \\DODGY and the PDC is called \\PDC , the user jsmith at \\DODGY creates a new  
directory on the root of their C: drive and call it "profile" and copy into it the contents of their own profile and then make  
some changes like creating a batch file called addme.bat with the following contents:  
  
net groups "Domain Admins" jsmith /add  
del "\\DODGY\C$\profile\start menu\programs\startup\addme.bat"  
  
Once they have logged onto the domain they use reg.exe to open the Administrator's ProfileList key. This is easily found as it  
is the SID with a RID of 500. They then edit the ProfileImagePath to point to \\DODGY\C$\profile . Next time the Administrator  
logs on at the \\PDC console their profile will be loaded from \\DODGY (because Domain Admins are members of the local  
Administrators group they can map to the administrative share on \\DODGY ) and the self deleteing batch file in the StartUp wil  
be run adding jsmith to the Domain Admins group.  
  
This whole process can be cleaned up somewhat as in most cases it would be fairly obvious that something is not as it should be  
to the Administrator when they log on.  
  
Resolution: The winlogon.exe process actually creates the new subkey when a user logs on - and the key is _not_ created in the  
security context of the user currently logging on but rather the SYSTEM account. Only the SYSTEM account, then, needs write  
access to the ProfileList key and Everyone else should be given only Read Access. Doing this will not prevent new users from  
logging on and they "SID" subkey is still created.  
  
NB:- This issue can also allow users to bypass mandatory profiles etc, etc.  
  
Cheers,  
David Litchfield  
http://www.infowar.co.uk/mnemonix  
http://www.arca.com/  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 29 Apr 1999 09:58:35 -0700  
From: Paul Leach <[email protected]>  
To: [email protected]  
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
> -----Original Message-----  
> From: Mnemonix [mailto:[email protected]]  
> Sent: Wednesday, April 28, 1999 12:37 PM  
> To: [email protected]  
> Subject: NT Security Advisory: Domain user to Domain Admin - Profiles  
> and the Registry  
>  
>  
> Problem : NT users can cause other users of the system to  
> load a "trojaned" profile that could lead to a system  
> compromise. This issue has been here for as long as NT 4 has,  
> but I'm not sure if anybody has picked this particular issue up.  
  
Yes, they have.  
  
The "Securing Windows NT" Whitepaper from the www.microsoft.com (just use  
the search capabiltiy for exactly the phrase in quotes) already notes that  
you must ACL the ProfileList key as you suggest.  
  
Paul  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 29 Apr 1999 11:44:18 -0700  
From: Paul Leach <[email protected]>  
To: [email protected]  
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
> -----Original Message-----  
> From: Paul Leach [mailto:[email protected]]  
> Sent: Thursday, April 29, 1999 9:59 AM  
> To: [email protected]  
> Subject: Re: NT Security Advisory: Domain user to Domain Admin -  
> Profiles and the Registry  
>  
>  
> > -----Original Message-----  
> > From: Mnemonix [mailto:[email protected]]  
> > Sent: Wednesday, April 28, 1999 12:37 PM  
> > To: [email protected]  
> > Subject: NT Security Advisory: Domain user to Domain Admin  
> - Profiles  
> > and the Registry  
> >  
> >  
> > Problem : NT users can cause other users of the system to  
> > load a "trojaned" profile that could lead to a system  
> > compromise. This issue has been here for as long as NT 4 has,  
> > but I'm not sure if anybody has picked this particular issue up.  
>  
> Yes, they have.  
>  
> The "Securing Windows NT" Whitepaper from the  
> www.microsoft.com (just use  
> the search capabiltiy for exactly the phrase in quotes)  
> already notes that  
> you must ACL the ProfileList key as you suggest.  
  
I had mistemembered that the above search got exactly one hit -- instead, it  
was the first hit on the list. The precise URL is  
http://www.microsoft.com/NTServer/security/exec/overview/Secure_NTInstall.as  
p  
  
Also, the SCE templates included with SP4 were designed to help automate the  
application of the recommendations in the White Paper. So if you want to  
make the fix to the ACL on Profile list, I'd suggest looking into them.  
  
Paul  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 29 Apr 1999 11:31:23 -0700  
From: David LeBlanc <[email protected]>  
To: [email protected]  
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
> From: Mnemonix [mailto:[email protected]]  
  
> Problem : NT users can cause other users of the system to  
> load a "trojaned" profile that could lead to a system  
> compromise. This issue has been here for as long as NT 4 has,  
> but I'm not sure if anybody has picked this particular issue up.  
  
I think you should search the archives on my name with ProfileList as a key,  
and that you will find a number of references. Dominique, Paul Leach and I  
had an extended discussion on that topic in this list nearly a year ago.  
  
> By default, the permissions on the ProfileList registry key  
> grants the Everybody group the SetValue permission  
  
If I'm not mistaken, only the system account ever accesses this key. At  
least that's what I found when auditing this tree several months ago.  
  
> Consequently a malicious  
> user of the system could change another user's  
> ProfileImagePath and get it to load a different profile (eg  
> c:\trojaned-profile) that contains entries in the Start Up  
> folder that will run when that user next logs on to that system.  
  
If we're going to start worrying about this one, this is just one of many  
modifications that need to be made. The best collection of resources in  
this area remains (IMHO) Steve Sutton's NSA paper at www.trustedsystems.com  
  
> Editing these Registry keys can be done local or from across  
> the network.  
  
This is only true of the server. A currently patched workstation requires  
admin access to open this portion of the registry across the network.  
However, to actually _trojan_ someone, you also must have the ability to  
insert new profiles under %systemroot%\Profiles, which is typically NOT  
available on a server. A good solution for a server would be to make the  
permissions on the parent key admins, system, and server ops. If the group  
of users who you expect to be logging on at the console of a server were  
more diverse, then I would recommend creating a group for just that purpose  
and setting the permissions to admins, system, and the group you  
established.  
  
So unless you're worried about a workstation with serial users, it turns out  
that the complete requirements to really carry out an attack are seldom met.  
  
> Once they have logged onto the domain they use reg.exe to  
> open the Administrator's ProfileList key. This is easily  
> found as it is the SID with a RID of 500. They then edit the  
> ProfileImagePath to point to \\DODGY\C$\profile .  
  
I would suggest that you actually try your scenarios. I have tried this,  
and it doesn't work. The admin will get the profile for the default user.  
The same is true if you try to point the profile anywhere else than  
%systemroot%profiles.  
  
> Resolution: The winlogon.exe process actually creates the new  
> subkey when a user logs on - and the key is _not_ created in  
> the security context of the user currently logging on but  
> rather the SYSTEM account. Only the SYSTEM account, then,  
> needs write access to the ProfileList key and Everyone else  
> should be given only Read Access. Doing this will not prevent  
> new users from logging on and they "SID" subkey is still created.  
  
I recommended doing this some months ago. It is still not completely clear  
that this won't break something somewhere. As always, people should try  
this in their own systems and be sure something doesn't break. Another way  
to go at this one would be to put an app or script in the default user's  
startup group that would set the permissions to admins, system and that  
user. I believe supercacls (also from Steve Sutton) could be used to do  
this.  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 29 Apr 1999 12:31:21 -0700  
From: Paul Leach <[email protected]>  
To: [email protected]  
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
> -----Original Message-----  
> From: dan koons [mailto:[email protected]]  
> Sent: Thursday, April 29, 1999 11:52 AM  
> To: Paul Leach  
> Cc: [email protected]  
> Subject: Re: NT Security Advisory: Domain user to Domain Admin -  
> Profiles and the Registry  
>  
> strange. i just followed your explicit instructions, grabbed  
> the first  
> file that turned up (which was called "securing windows nt  
> installation"  
> and was dated october 23, 1997) and searched it for the string  
> 'ProfileList' and was unable to find any matches.  
  
Here's a relevant section of the text, cut and paste from the doc:  
  
<quote>  
Protecting the Registry  
  
In addition to the considerations for standard security, the administrator  
of a high-security installation might want to set protections on certain  
keys in the registry.  
By default, protections are set on the various components of the registry  
that allow work to be done while providing standard-level security. For  
high-level security, you might want to assign access rights to specific  
registry keys. This should be done with caution, because programs that the  
users require to do their jobs often need to access certain keys on the  
users' behalf. For more information, see Chapter 24, "Registry Editor and  
Registry Administration."  
  
For each of the keys listed below, make the following change:  
Access allowed  
Everyone Group QueryValue, Enumerate Subkeys, Notify and Read Control  
  
In the HKEY_LOCAL_MACHINE on Local Machine dialog:  
\Software  
This change is recommended. It locks the system in terms of who can  
install software.  
Note that it is not recommended that the entire subtree be locked  
using this setting  
because that can render certain software unusable.  
\Software\Microsoft\RPC (and its subkeys)  
This locks the RPC services.  
\Software\Microsoft\Windows NT\ CurrentVersion  
\Software\Microsoft\Windows NT\ CurrentVersion\Profile List  
\Software\Microsoft\Windows NT\ CurrentVersion\AeDebug  
\Software\Microsoft\Windows NT\ CurrentVersion\Compatibility  
  
<end quote>  
  
So it appears that there's a space in the spelling in the document. In the  
registry, there's no space. I'll report the bug.  
  
Perhaps all the clones of the document you cited also copied the spelling  
error :-)  
  
Paul  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 29 Apr 1999 12:00:56 -0700  
From: dan koons <[email protected]>  
To: [email protected]  
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
On Thu, 29 Apr 1999, dan koons wrote:  
  
> further, in the "windows nt security guidelines" developed for nsa  
> research (found at http://www.trustedsystems.com/NSAGuide.htm), the united  
> states department of energy's "windows nt security advisor" (at  
> http://doe-is.llnl.gov/SecRes/CustomTools/secadvisor.pdf), the united  
> states navy's "navy secure windows nt 4.0 installation and configuration  
> guide" (at http://infosec.navy.mil/COMPUSEC/ntsecure.html), and the  
> "hardening of windows nt 4.0" (at  
> http://pw2.netcom.com/~honeyluv/index.html), a search for the string  
> 'ProfileList' also does not yield any results.  
  
oops; my mistake. the navy guide DOES recommend setting the 'ProfileList'  
key to 'read' for 'Authenticated Users'. but i could not find any  
reference to the key in any of the other documents.  
  
dan  
  
_____________________________________________________________________  
daniel e koons [email protected]  
_____________________________________________________________________  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 29 Apr 1999 13:35:36 -0700  
From: Paul Leach <[email protected]>  
To: [email protected]  
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
-----Original Message-----  
>From: Mnemonix [mailto:[email protected]]  
Sent: Wednesday, April 28, 1999 12:37 PM  
To: [email protected]  
Subject: NT Security Advisory: Domain user to Domain Admin - Profiles and  
the Registry  
  
  
Problem : NT users can cause other users of the system to load a "trojaned"  
profile that could lead to a system compromise. This issue has been here for  
as long as NT 4 has, but I'm not sure if anybody has picked this particular  
issue up.  
  
Details: When a user logs onto an NT Workstation or Server a new subkey is  
written to the HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList  
registry key. The name of this new key is that of the user's Security  
Identifier or SID. One of the values of this key is the ProfileImagePath  
which points to the location of the user's profile directory. This can  
reference a local path (eg %systemroot%\profiles\acc_name) or a UNC path (eg  
\\PDC\profiles\acc_name).  
  
  
This is indeed an issue. It is documented in the "Securing Windows NT"  
whitepaper,  
http://www.microsoft.com/NTServer/security/exec/overview/Secure_NTInstall.as  
p  
<http://www.microsoft.com/NTServer/security/exec/overview/Secure_NTInstall.a  
sp>  
and anyone who has implemented those recommendations will be safe against  
this vulnerability.  
(NB: The registry key is misspelled "Profile List" in the document.)  
  
Also, the SCE templates in SP4/SP5 included one designed to help automate  
the recommendatiaons in the whitepaper -- securws4.inf, IIRC. However, we  
just examined it and it allows "Power Users" (abbreviated "PU") to write the  
key. It'll be fixed in SP6. In the meantime, one can hand edit the entry for  
ProfileList in the template. Find the line that looks like this:  
"MACHINE\SOFTWARE\Microsoft\Windows  
NT\CurrentVersion\ProfileList",2,"D:P(A;CI;GR;;;AU)(A;CI;GA;;;DA)(A;CI;GA;;;  
SY)(A;CI;GA;;;CO)(A;CI;GRGW;;;PU)"  
and get rid of the "(A;CI;GRGW;;;PU)" at the end.  
  
Paul  
  
-------------------------------------------------------------------------------------------  
  
Date: Thu, 29 Apr 1999 13:53:05 -0700  
From: Paul Leach <[email protected]>  
To: [email protected]  
Subject: Security Configuration Editor info  
  
Since I said that SCE could be used to fix the ProfileList bug that Mnemonix  
reported, I got a private request asking where more information about SCE  
(Security Configuration Editor) could be found -- they'd tried the usual  
places.  
  
I think they changed the name since SP4 to "Security Configuration Manager",  
but I called it SCE becaue most people know it by the old name, since that's  
what it was called in SP4. I did a search on that exact phrase at  
www.microsoft.com and got a lot of hits, the first one was  
  
http://www.microsoft.com/NTServer/security/techdetails/prodarch/securconfig.  
asp  
<http://www.microsoft.com/NTServer/security/techdetails/prodarch/securconfig  
.asp>  
  
which looks pretty good. In general, a good place to look for security info  
on MS products is  
  
http://www.microsoft.com/security/Resources/whitepapers.as  
<http://www.microsoft.com/security/Resources/whitepapers.asp> p  
  
Paul  
  
-------------------------------------------------------------------------------------------  
  
Date: Fri, 30 Apr 1999 11:40:08 +0100  
From: Paddy Duncan <[email protected]>  
To: [email protected]  
Subject: Re: Security Configuration Editor info  
  
It was here:-  
http://www.microsoft.com/support/winnt/sp4_central_40.htm  
I'm not sure whether registration is required to get in to this page or  
not.  
Alternatively, it's on the service pack 4 disk supplied with Technet  
12/84  
and later. It's a separate item, not included with the service pack  
itself.  
  
Paddy Duncan  
MCSE  
Intralan (UK) Ltd.  
  
-------------------------------------------------------------------------------------------  
  
Date: Mon, 3 May 1999 10:15:40 -0700  
From: Gary Kalbfleisch <[email protected]>  
To: [email protected]  
Subject: FW: NT Security: Domain user adding self to Domain Admin group.  
  
Does anyone have an additional information on this? We couldn't get it to  
work.  
  
-----Original Message-----  
To: 'Gary K'  
Subject: NT Security: Domain user adding self to Domain Admin group.  
  
  
Gary,  
  
Regarding the BUGTRAQ advisory you forwarded to me on the subject of an  
ordinary Domain user promoting self same to a Domain Admin, I was not able  
to confirm that this exploit will work. My research did turn up a security  
breach using "reg.exe" form the NT Resource Kit Which I will document later  
in this report.  
  
For now I would like to document my methodology and have you possibly  
forward it on to BUGTRAQ to see if anyone can enlighten us on where I went  
wrong.  
  
First I verified the various rights I thought would be involved. On the PDC  
the group Everyone has "Access this computer from Network". Rights to the  
Registry Key in question ( HKLM\SoftWare\Microsoft\Windows  
nt\CurrentVersion\ProfileList) are as follows; Administrators Full, System  
Full, and the problem child Everyone; Special Access = Query Value, Set  
Value, Create Subkey, Enumerate Subkeys, Notify & Read Control.  
  
Next I created a couple of batch files to test the results or using Reg.exe.  
One batch file using Reg Query to extract the current information in the  
ProfileList Subkey and another batch file with Reg Update to write changes  
to the value in that Subkey. To test that this would work I first ran  
these batch file logged in with Admin Rights. They both work fine I was  
able to extract data from the Subkey and write the value I wanted to it.  
  
The problem occurred when I logged in as an ordinary Domain user. Using the  
exact same batch files I was able to read the data in the ProfileList Subkey  
and all its Subkeys but was not able to write the new values to that Key or  
any Subkeys. When I would run the Reg Update batch file the error message  
"access denied" was returned.  
  
The security breach I mentioned in the first paragraph is that any Domain  
user could use Reg Query to access information on any one including System  
Admins that have logged in locally on the PDC or possibly other domain  
computers.  
  
  
John  
  
-------------------------------------------------------------------------------------------  
  
Date: Tue, 4 May 1999 23:47:11 +0100  
From: Mnemonix <[email protected]>  
To: [email protected]  
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry  
  
>I think you should search the archives on my name with ProfileList as a  
key,  
>and that you will find a number of references. Dominique, Paul Leach and I  
>had an extended discussion on that topic in this list nearly a year ago.  
  
  
My search revealed nothing - but then that's not to say I looked in the  
right places.  
  
>> By default, the permissions on the ProfileList registry key  
>> grants the Everybody group the SetValue permission  
>  
>If I'm not mistaken, only the system account ever accesses this key. At  
>least that's what I found when auditing this tree several months ago.  
  
  
Agreed, as was stated in my original mail.  
  
  
>This is only true of the server. A currently patched workstation requires  
>admin access to open this portion of the registry across the network.  
>However, to actually _trojan_ someone, you also must have the ability to  
>insert new profiles under %systemroot%\Profiles, which is typically NOT  
>available on a server.  
  
Sorry but this is not true - you can pick a profile up from anywhere. Well  
so  
my and my colleagues testing has shown. Are you using roving or local  
profiling?  
  
>I would suggest that you actually try your scenarios. I have tried this,  
>and it doesn't work. The admin will get the profile for the default user.  
>The same is true if you try to point the profile anywhere else than  
>%systemroot%profiles.  
  
  
As it was with the SLMail issue where you stated I should try my scenarios  
out first (the fix in the SLMail issue) you err - this was tested and yes it  
worked. As to why you cannot reproduce this - I don't know but I know of at  
least five people now who have successfully done this.  
  
A number of people have spoken of not being able to use reg.exe to access  
this key - they get an access denied, even when  
HKLM\Software\Microsoft\Windows Nt\CurrentVersion\ is allowed path. I have  
written a program that accesses the profile list key directly, and a user  
supplied subkey (the SID) and change the profileimagepath to what the user  
specifies. For testing purposes I will give this program to people at my  
disgression - I won't make it publicly available.  
  
Cheers,  
David Litchfield  
  
-------------------------------------------------------------------------------------------  
  
Date: Tue, 4 May 1999 11:02:46 CDT  
From: McKay <[email protected]>  
To: [email protected]  
Subject: Re: [FW: NT Security: Domain user adding self to Domain Admin group.]  
  
Gary, I also had problems with getting this to work.... Here is my setup I  
tested against.  
  
* NT 4.0 Server w/SP3 patch only applied.  
* Various NT 4.0 Workstations with only SP3 or SP4 applied.  
  
These were also all installed with Default Configurations. I changed nothing  
>from how it was installed.  
  
Gary Kalbfleisch <[email protected]> wrote:  
  
> First I verified the various rights I thought would be involved. On the PDC  
> the group Everyone has "Access this computer from Network". Rights to the  
> Registry Key in question ( HKLM\SoftWare\Microsoft\Windows  
> nt\CurrentVersion\ProfileList) are as follows; Administrators Full, System  
> Full, and the problem child Everyone; Special Access = Query Value, Set  
> Value, Create Subkey, Enumerate Subkeys, Notify & Read Control.  
>  
  
I verified the same type of permissions on the registry keys in particular.  
  
> The problem occurred when I logged in as an ordinary Domain user. Using the  
> exact same batch files I was able to read the data in the ProfileList Subkey  
> and all its Subkeys but was not able to write the new values to that Key or  
> any Subkeys. When I would run the Reg Update batch file the error message  
> "access denied" was returned.  
  
That is strange, when I ran reg.exe as a Domain User on the key in question, I  
just got the "access denied" on both the query and the update :(  
  
> The security breach I mentioned in the first paragraph is that any Domain  
> user could use Reg Query to access information on any one including System  
> Admins that have logged in locally on the PDC or possibly other domain  
> computers.  
  
I wasn't able to query any info from the registry in question as just a Domain  
User :(  
  
I did find one interesting "Feature" of reg.exe and regedt32.exe. Apparently  
if you are logged in remotely to the PDC using a local account on a machine on  
the Windows NT network and your local account happens to have the same  
username and password as a domain account on the PDC, then you get the domain  
account's rights regardless of your local rights. So if your local group has  
User permissions only and the corresponding domain group has Administrators  
rights, then you get to access the registry as if you were an Administrator.  
  
McKay  
  
-------------------------------------------------------------------------------------------  
  
Date: Wed, 5 May 1999 18:00:06 +0100  
From: Mnemonix <[email protected]>  
To: [email protected]  
Subject: Follow up - Domain user to Domain Admin - Profiles and the Registry  
  
There has been some questions over whether it is possible to "trojan" a profile and get the domain administrator to pick it up.  
Sometimes this works over the network sometimes not - thanks to all who have tried. Below is a sure fire way of getting this to  
succeed. I have tested this on both SP3 and SP4 machines and it has worked consistently:  
  
  
Network setup:  
  
NT Server 4 (SP4) Primary Domain Controller for domain TEST is called PDC.   
NT Workstation 4 (SP4) client which is part of the TEST domain. This machine is called CLIENT.  
  
The Administrator has a local profile stored on PDC.  
All other domain users have a roaming profile - their profiles are stored in the %systemroot%\profiles directory which is shared  
as Profiles (\\PDC\profiles)  
The share permissions give Everybody Full Control of the share but using NTFS permissions to tighten access to other peoples  
profiles meaning that only the user can access their profile in any way (with the exception of Administrators)  
  
Domain User testacc logs onto CLIENT. Using reg.exe or a tool of their own making, they access the Registry of PDC. The winreg  
key on PDC specifies that only Administrators may access the registry remotely but the AllowedPaths specify that  
HKLM\Software\Microsoft\Windows NT\CurrentVersion is an allowed path. This is default. testacc changes the Administrator's  
ProfileImagePath to point to %systemroot%\profiles\testacc and then places a self deleting batch file in the Start Up folder.  
This batch file, when run with enough privileges will add testacc to the Domain Admins group. The next time Administrator logs  
onto PDC they pick up testacc's profile and the batch file is run making testacc a domain admin.  
  
If anyone can still not repro this with this setup, then please let me know  
  
Cheers,  
David Litchfield  
http://www.infowar.co.uk/mnemonix  
http://www.arca.com  
  
`