Backdoor in active directory do it yourself
So, we all know about mean users with UID = 0 in 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 are not going to talk about local Windows accounts, but about Active Directory, i.e. let's talk about the domain administrator. Or, even worse, about the enterprise administrator.
So, the truth is number one: objects in active directory have attributes and access rights.
Truth number two: these attributes can be changed.
')
As it is easy to understand, we CAN make an account with fantastic rights to which no one can access. However, he will be able to login, 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 delete. (To do this, rename, and in its place put another user with the nickname Administrator and with full rights).
Thus, we will get a formally clean little white fluffy domain, inside of which lives a big, fat ... m ... I do not even know who. Well, let him be called the northern fur-bearing beast.
Steps to perform:
1) Create an account or rename an administrator. Call her very ... weird. For example, ExchangeLegacyReciver. In the usual case, there is ExchangeLegacyInterop, so it’s very difficult to understand what it’s all about.
2) Give her the appropriate name. Like, Exchange Legacy Connection Reciver.
3) Give her a password, specify “the password never expires”, etc.
4) Include it in all the right groups. In fact, to control the domain, it is enough to enter the Remote Desktop Users (or another group specified in the tcp-RDP properties) and the Enterprise Administrator. The smaller
Then the magic begins:
1) Login under this account.
2) We run ads * (if you don’t know what the stars are in place, you don’t need it. Those who know and understand what they are talking about, please don’t answer school hacker questions about the missing part)
3) We are looking for ourselves in the right OU. First of all we 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 it)
4) Remove the inheritance checkbox, copy the attributes.
And ... Well, you understand. Remove all unnecessary. Removing SYSTEM from those who have the right will lead to a strange situation: even an account cannot change its attributes via snap-ins, however, it can edit them through ads *; add yourself full rights to yourself.
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, move simply to the domain root.
6) Check the rights after the move (they like to append)
7) do the trick with the container. This will not allow outsiders not only to change the attributes or read them, but also to see the fact of existence.
Consider, during all this - one mistake - and you are no longer the owner of yourself without the right to restore.
Actually, one can say almost everything. You can (checking that login, etc. is good), change the user's owner to himself. Point chain closed. Then only restore from backup. The most funny thing is that 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, recover from backup).
So:
1) Rename the group (through ads) to something your own. For example, Builtin Security Principial.
2) Create an Enterprise Administrator. We include it in Builtin Security Principial.
3) Move Builtin Security Principial to program data \ system
4) make him a similar "magic" with the rights.
5) PROFIT ???
See it will be. Alas. I did not manage to hide the membership until the end (although you can create a chain ...) However, when I try to remove you from the group members, there will be an error there is no such object on server.
Wherein:
1) enterprise and domain admins still have a right to exist. The group is there, its rights are correct, the domain is working as expected (I did not check the installation of the ecchain, though).
2) There is an account that is IMPOSSIBLE to see. No None of the ads * or anything else (you can see a strange container, but no more).
3) Membership in groups at this account is not noticeable.
A further level of stealth is to try to change the type of group and user to something else (for example, to a computer). Not sure that this is possible, and that it will be adequately perceived by computers on the network.
PS I apologize, I wrote messy as I look for a solution to the problems. Tomorrow, if there is time, I will raise the virtual machine from 2008, check it out there in full.
Let's see how the same (and in fact, even more terrible) is organized in the Windows infrastructure. Of course, we are not going to talk about local Windows accounts, but about Active Directory, i.e. let's talk about the domain administrator. Or, even worse, about the enterprise administrator.
So, the truth is number one: objects in active directory have attributes and access rights.
Truth number two: these attributes can be changed.
')
As it is easy to understand, we CAN make an account with fantastic rights to which no one can access. However, he will be able to login, 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 delete. (To do this, rename, and in its place put another user with the nickname Administrator and with full rights).
Thus, we will get a formally clean little white fluffy domain, inside of which lives a big, fat ... m ... I do not even know who. Well, let him be called the northern fur-bearing beast.
Steps to perform:
1) Create an account or rename an administrator. Call her very ... weird. For example, ExchangeLegacyReciver. In the usual case, there is ExchangeLegacyInterop, so it’s very difficult to understand what it’s all about.
2) Give her the appropriate name. Like, Exchange Legacy Connection Reciver.
3) Give her a password, specify “the password never expires”, etc.
4) Include it in all the right groups. In fact, to control the domain, it is enough to enter the Remote Desktop Users (or another group specified in the tcp-RDP properties) and the Enterprise Administrator. The smaller
Then the magic begins:
1) Login under this account.
2) We run ads * (if you don’t know what the stars are in place, you don’t need it. Those who know and understand what they are talking about, please don’t answer school hacker questions about the missing part)
3) We are looking for ourselves in the right OU. First of all we 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 it)
4) Remove the inheritance checkbox, copy the attributes.
And ... Well, you understand. Remove all unnecessary. Removing SYSTEM from those who have the right will lead to a strange situation: even an account cannot change its attributes via snap-ins, however, it can edit them through ads *; add yourself full rights to yourself.
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, move simply to the domain root.
6) Check the rights after the move (they like to append)
7) do the trick with the container. This will not allow outsiders not only to change the attributes or read them, but also to see the fact of existence.
Consider, during all this - one mistake - and you are no longer the owner of yourself without the right to restore.
Actually, one can say almost everything. You can (checking that login, etc. is good), change the user's owner to himself. Point chain closed. Then only restore from backup. The most funny thing is that 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, recover from backup).
So:
1) Rename the group (through ads) to something your own. For example, Builtin Security Principial.
2) Create an Enterprise Administrator. We include it in Builtin Security Principial.
3) Move Builtin Security Principial to program data \ system
4) make him a similar "magic" with the rights.
5) PROFIT ???
See it will be. Alas. I did not manage to hide the membership until the end (although you can create a chain ...) However, when I try to remove you from the group members, there will be an error there is no such object on server.
Wherein:
1) enterprise and domain admins still have a right to exist. The group is there, its rights are correct, the domain is working as expected (I did not check the installation of the ecchain, though).
2) There is an account that is IMPOSSIBLE to see. No None of the ads * or anything else (you can see a strange container, but no more).
3) Membership in groups at this account is not noticeable.
A further level of stealth is to try to change the type of group and user to something else (for example, to a computer). Not sure that this is possible, and that it will be adequately perceived by computers on the network.
PS I apologize, I wrote messy as I look for a solution to the problems. Tomorrow, if there is time, I will raise the virtual machine from 2008, check it out there in full.
Source: https://habr.com/ru/post/90990/
All Articles