April 14, 2010 at 21:10DIY backdoor in active directory
So, we all know about vile users with UID = 0 on unix, which can be more than one.
Let's see how the same (and in fact, even more terrible) is organized in the Windows infrastructure. Of course, we will not talk about local Windows accounts, but about Active Directory, i.e. We will talk about the domain administrator. Or, even worse, about the enterprise administrator.
So, truth number one: objects in the active directory have attributes and permissions.
Truth number two: these attributes can be changed.
As it is easy to understand, we CAN make an account with fantastic rights that NO ONE will have access to. However, he will be able to log in, block, unblock, change his attributes and attributes of strangers.
In the worst case, it will be a user with a magic SID- * 500, which Windows itself does not allow to remove. (To do this, rename, and in its place put another user with the nickname Administrator and with full rights).
Thus, we get a formally clean little white fluffy domain, inside which lives a big, bold ... m ... I don’t even know who. Well, let him be called the northern fur-bearing animal.
Steps to complete:
1) Create an account or rename the administrator. Call her very ... weird. For example, ExchangeLegacyReciver. There is ExchangeLegacyInterop in the usual chaining, so it’s very, very difficult to understand what this is about.
2) Give her the appropriate name. Like, Exchange Legacy Connection Reciver.
3) Give her a password, indicate “the password never expires”, etc.
4) Include it in all the necessary groups. Actually, to control the domain, entering into Remote Desktop Users (or another group specified in the tcp-RDP properties) and Enterprise Administrator is enough. The less.
Then the magic begins:
1) Log in under this account.
2) Run ads * (if you don’t know what the stars are there, you don’t need it. For those who know and understand what they’re talking about, please do not answer questions from school hackers about the missing part)
3) We look for ourselves in the right OU. First of all, go to the properties and change the owner to some other account with sufficient rights (so that, if we make a mistake, we can change or delete)
4) Uncheck the inheritance, copy the attributes.
And ... Well, you get the point. We remove all unnecessary. Removing SYSTEM from those who have the right will lead to a strange situation: even an account cannot change its attributes through snap-ins, however, it can edit them through ads *; we add to ourselves full rights to ourselves.
5) Create a new System container in ou = Program data
5) Move the object (right-click, move) to, for example, Program Data. This place is never visible to anyone. Those. your object will exist "somewhere", where it will be visible only through ads * or similar utilities. Alternatively, simply move to the root of the domain.
6) Check the rights after moving (they like to add them)
7) do the rights trick with the container. This will not allow outsiders not only to change attributes or read them, but also to see the fact of existence.
Remember, during all this - one mistake - and you are no longer the owner of yourself without the right to recovery.
Actually, you can say almost everything. You can (checking that the login, etc. is good), change the owner of the user to himself. Point, the chain is closed. Next, only recovery from backup. The funny thing is, other users with full rights will not even see you in the active directory. Even in ads *.
Then it remains only to securitize the main thing - this is group membership (one wrong step - and you are a corpse, restore from backup).
So:
1) Rename the group (through ads) to something of their own. For example, Builtin Security Principial.
2) Create an Enterprise Administrator. We include it in the Builtin Security Principial.
3) We move Builtin Security Principial to program data \ system
4) we make it a similar "magic" with rights.
5) PROFIT ???
VISIBLE it will be. Alas. I was unable to hide the membership until the end (although you can create a chain ...) However, when you try to remove you from the group members, an error will appear there is no such object on server.
At the same time:
1) enterprise and domain admins still have the right to exist. There is a group, its rights are correct, the domain works as expected (I did not check the installation of the chain, though).
2) There is an account that is IMPOSSIBLE to see. No way. Neither from ads * nor from anything else (you can see a strange container, but no more).
3) Membership in groups at this account is not noticeable.
A further stealth level is to try changing the type of group and user to something else (for example, to a computer). I'm not sure that this is possible, and that this will be adequately perceived by computers on the network.
PS I apologize, wrote chaotically as I searched for a solution to the problems. Tomorrow, if there is time, I’ll raise the virtual machine from 2008, I’ll check it there in full.
Let's see how the same (and in fact, even more terrible) is organized in the Windows infrastructure. Of course, we will not talk about local Windows accounts, but about Active Directory, i.e. We will talk about the domain administrator. Or, even worse, about the enterprise administrator.
So, truth number one: objects in the active directory have attributes and permissions.
Truth number two: these attributes can be changed.
As it is easy to understand, we CAN make an account with fantastic rights that NO ONE will have access to. However, he will be able to log in, block, unblock, change his attributes and attributes of strangers.
In the worst case, it will be a user with a magic SID- * 500, which Windows itself does not allow to remove. (To do this, rename, and in its place put another user with the nickname Administrator and with full rights).
Thus, we get a formally clean little white fluffy domain, inside which lives a big, bold ... m ... I don’t even know who. Well, let him be called the northern fur-bearing animal.
Steps to complete:
1) Create an account or rename the administrator. Call her very ... weird. For example, ExchangeLegacyReciver. There is ExchangeLegacyInterop in the usual chaining, so it’s very, very difficult to understand what this is about.
2) Give her the appropriate name. Like, Exchange Legacy Connection Reciver.
3) Give her a password, indicate “the password never expires”, etc.
4) Include it in all the necessary groups. Actually, to control the domain, entering into Remote Desktop Users (or another group specified in the tcp-RDP properties) and Enterprise Administrator is enough. The less.
Then the magic begins:
1) Log in under this account.
2) Run ads * (if you don’t know what the stars are there, you don’t need it. For those who know and understand what they’re talking about, please do not answer questions from school hackers about the missing part)
3) We look for ourselves in the right OU. First of all, go to the properties and change the owner to some other account with sufficient rights (so that, if we make a mistake, we can change or delete)
4) Uncheck the inheritance, copy the attributes.
And ... Well, you get the point. We remove all unnecessary. Removing SYSTEM from those who have the right will lead to a strange situation: even an account cannot change its attributes through snap-ins, however, it can edit them through ads *; we add to ourselves full rights to ourselves.
5) Create a new System container in ou = Program data
5) Move the object (right-click, move) to, for example, Program Data. This place is never visible to anyone. Those. your object will exist "somewhere", where it will be visible only through ads * or similar utilities. Alternatively, simply move to the root of the domain.
6) Check the rights after moving (they like to add them)
7) do the rights trick with the container. This will not allow outsiders not only to change attributes or read them, but also to see the fact of existence.
Remember, during all this - one mistake - and you are no longer the owner of yourself without the right to recovery.
Actually, you can say almost everything. You can (checking that the login, etc. is good), change the owner of the user to himself. Point, the chain is closed. Next, only recovery from backup. The funny thing is, other users with full rights will not even see you in the active directory. Even in ads *.
Then it remains only to securitize the main thing - this is group membership (one wrong step - and you are a corpse, restore from backup).
So:
1) Rename the group (through ads) to something of their own. For example, Builtin Security Principial.
2) Create an Enterprise Administrator. We include it in the Builtin Security Principial.
3) We move Builtin Security Principial to program data \ system
4) we make it a similar "magic" with rights.
5) PROFIT ???
VISIBLE it will be. Alas. I was unable to hide the membership until the end (although you can create a chain ...) However, when you try to remove you from the group members, an error will appear there is no such object on server.
At the same time:
1) enterprise and domain admins still have the right to exist. There is a group, its rights are correct, the domain works as expected (I did not check the installation of the chain, though).
2) There is an account that is IMPOSSIBLE to see. No way. Neither from ads * nor from anything else (you can see a strange container, but no more).
3) Membership in groups at this account is not noticeable.
A further stealth level is to try changing the type of group and user to something else (for example, to a computer). I'm not sure that this is possible, and that this will be adequately perceived by computers on the network.
PS I apologize, wrote chaotically as I searched for a solution to the problems. Tomorrow, if there is time, I’ll raise the virtual machine from 2008, I’ll check it there in full.