what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

nt4.trojaned.profiles.txt

nt4.trojaned.profiles.txt
Posted Aug 17, 1999
Authored by Mnemonix

Bad permissions on Windows NT ProfileList registry subkeys allow any malicious NT user to cause other users of the system to load a "trojaned" profile that could lead to a system compromise. Exploit description and vendor solution included.

tags | exploit, trojan, registry
systems | windows
SHA-256 | 54057eb398a0eeecb0fcb718eabe86ff4593d8772f67adaac7ec2fed79e5fad7

nt4.trojaned.profiles.txt

Change Mirror Download
Date: Wed, 28 Apr 1999 20:36:58 +0100
From: Mnemonix <mnemonix@GLOBALNET.CO.UK>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
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 <paulle@MICROSOFT.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry

> -----Original Message-----
> From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK]
> Sent: Wednesday, April 28, 1999 12:37 PM
> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> 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 <paulle@MICROSOFT.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry

> -----Original Message-----
> From: Paul Leach [mailto:paulle@MICROSOFT.COM]
> Sent: Thursday, April 29, 1999 9:59 AM
> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> Subject: Re: NT Security Advisory: Domain user to Domain Admin -
> Profiles and the Registry
>
>
> > -----Original Message-----
> > From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK]
> > Sent: Wednesday, April 28, 1999 12:37 PM
> > To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> > 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 <dleblanc@MICROSOFT.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry

> From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK]

> 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 <paulle@MICROSOFT.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry

> -----Original Message-----
> From: dan koons [mailto:dkoons@secured.net]
> Sent: Thursday, April 29, 1999 11:52 AM
> To: Paul Leach
> Cc: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
> 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 <dkoons@SECURED.NET>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
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 dkoons@secured.net
_____________________________________________________________________

-------------------------------------------------------------------------------------------

Date: Thu, 29 Apr 1999 13:35:36 -0700
From: Paul Leach <paulle@MICROSOFT.COM>
To: BUGTRAQ@netspace.org
Subject: Re: NT Security Advisory: Domain user to Domain Admin - Profiles and the Registry

-----Original Message-----
>From: Mnemonix [mailto:mnemonix@GLOBALNET.CO.UK]
Sent: Wednesday, April 28, 1999 12:37 PM
To: BUGTRAQ@NETSPACE.ORG
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 <paulle@MICROSOFT.COM>
To: BUGTRAQ@netspace.org
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 <PaddyD@INTRALAN.CO.UK>
To: BUGTRAQ@netspace.org
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 <gkalbfle@CTC.CTC.EDU>
To: BUGTRAQ@netspace.org
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 <mnemonix@GLOBALNET.CO.UK>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
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 <seanmckay@NETSCAPE.NET>
To: BUGTRAQ@netspace.org
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 <gkalbfle@CTC.CTC.EDU> 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 <mnemonix@GLOBALNET.CO.UK>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
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

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close