Insert 'Skeleton Key', unlock Microsoft Active Directory. Simples – hackers Miscreants have forged a strain of malware which is capable of bypassing authentication on Microsoft Active Directory (AD) systems. Hackers can use arbitrary passwords to authenticate as any corporate user, Dell SecureWorks warns. The malware, dubbed Skeleton Key, is deployed as an in-memory patch on a victim’s AD domain …
@Lost all Faith...
But the needing an AD Admin creds to start off is only the first step in the elevation of attack/intrusion.
Thinking a bit farther. What a wonderful way to foobar a lot of shit, reboot on your way out.... Lock the door and slide the key under the door as they say. Realize you've forgotten to wreak havoc on something, log back in, apply the patch again do your nasty... rinse and repeat!
Paris because she knows about rinsing and repeating...
As Lost all Faith says, the key here is that you can do "the dirty" in the name of somebody else, without leaving a trail back to yourself.
The good side is, that the attacker needs admin access to the domain controller in the first place, in order to plant the malware. If he can do that, then you have bigger problems than Skeleton Key. Either hackers have taken over your network, or you have an employee with a grudge and the keys to the system.
SK isn't good, but it is probably the least of your concerns by that point - of course, if it is done properly, you won't know that there is anything wrong, or the PFY is busy setting up the bean counters, so that he can get his next big pay rise.
If you already have the domain admin credentials why would you need this piece of temporary, only works until the next reboot malware?
I don't understand where the problem even is.
You want to have someone (who is not you) who has the domain admin credentials install this little baby on behalf of you. Maybe using an USB stick.
Whether it remains in memory due to inability to write on disk or to stay undetected I don't know. But are DCs rebooted often?
Reason for installing it is (assuming I have read the page correctly) that it allows you to impersonate ANOTHER user on your domain with any password you choose.
That means you can log onto webmail as your CEO and read all his email or your boss etc etc etc without there being any audit trail of you doing so.
I can't see a reason for doing this but I know one or two people at places I have worked that would have no qualms using it for that reason. AC for that very reason!!!
My theory is that somewhere there is an organization kind of like Accenture, but for hackers.....
"Need domain admin access to corporation X's network? Sure! That will be $2000/day or $8000/week."
"I'll just need it for one day. After that I will have malware in place"
"Sounds fine. Here's your SoW. Please submit payment to our accounts receivable department in Lagos, Nigeria"
"I don't object to El Reg including a headline picture with its articles. But some of them really do make the site look tacky."
Couple of clicks through Adblock Plus removes them. Initially during the el reg changeover, I had left them in, but found too many wheren't really applicable to the story - so out they went.
"sounds brilliant- Microsoft's version of Single Sign On appears to be based on the concept of constantly logging in to everything you ever use the whole time. "
Nope - it's based on Kerberos - which issues 'tickets' with a defined lifetime. No need to constantly log on.
Yep - there is no need to not patch these things along with everything else. There is no reason not to because you should have at least two of them per domain. There are no functions that either one can't do on its own or you can live without for the time for a reboot.
Any tosser who pipes up hard coded LDAP server in my dodgy app should note that all DCs can be referred to collectively by their domain name and a proper app would walk DNS to find the right one for the site if necessary. As a last resort for insanely large non subdivided domains you can make use of custom DNS round robin entries or put two LDAP servers in.
I agree completely.
The biggest problem is small IT shops where, actually, the DC is misused as not only the DC but also the primary file store, profile store, etc. Even if they have a secondary / tertiary DC, they can't just reboot them because they don't have adequate DFS setups etc. to cope with one server going down.
Hell, I've seen schools who have Exchange on the DC (which is a totally unsupported configuration) because they don't want to have lots of expensive servers running (Most of them haven't caught up with modern VM technology, either).
A lot of it comes from the legacy of 2000/2003 where a lot of functions couldn't be failed-over to other servers properly or easily (e.g. DHCP, DFS, etc.).
Also, because it's a "DC" it's seen as some mystical magical configuration that must never be rebooted even if you have a secondary.
Hopefully as we move forward into VM'd configurations, such a mindset will be phased out.
"There are no functions that either one can't do on its own or you can live without for the time for a reboot."
Untrue. FSMO roles run on only one DC. In large enough domain/forest they become important enough that they cannot be restarted just like that.
Sorry FSMO roles dont HAVE to only sit on one DC. In fact in most large organisations I have worked they have had an empty root domain which will have DC's hosting some of the FSMO roles and then the child domains hosting the others.
Also if it was that important that the FSMO roles were available during a reboot (and I really can't think of any reason off the top of my head) - surely you would just transfer the role to another DC first before reboot.
You can argue on semantics (and downvote) but each of the FSMO roles can run on only one DC per forest/domain (some are per forest some per domain) as you clearly know.
My reply was about the "only one DC" which clearly was not true in the case of Ops Masters. Of course they should be transferred out before boot but the OP did not mention it.
So they discovered "SeImpersonatePrivilege" in the API, big fuckin' deal. Hell, you could do this with the SysInternal's 'psexec' tool.
But if you have Domain Admin rights, you could just edit the schema and create some random account buried deep in the System container and give yourself every right you want. Or if you are just wanting to look at someone's email, just log onto the Exchange server and mount their mailbox (Use 'psexec -sie' to impersonate SYSTEM and no one would ever notice, or they'll assume it was Exchange itself doing it).
PSEXEC requires you know the password of the user you intend to impersonate, as do many other Windows commands (i.e. Run As), or to have rights to run as the system account which would still how up in the system log, if only until the default purge. This malware does not, so it is not quite the same thing. As far as creating an account with admin privileges and giving it some hard to detect name or AD container, some of us monitor stuff like that. My guess is the point of this malware is that it can be used to target shops that have a high level of paranoia and security procedures to match. It would be very difficult to track it back to its origin even if its fingerprints were found. It could be used to create a significant amount of chaos in highly secure environments by setting different individuals up as bad actors. It's not that these things cannot be accomplished by other means, it's just that this way will be much more effective.
So let me get this straight... Some malware that somehow finds itself executing on a DC with sufficient local system access (not necessarily "domain admin") can alter the in-memory code of the authentication process and insert its own tweaks to let specific passwords through as well as the correct ones.
Clever but, well, duh. When a process has full access to all memory in a system it can make all kinds of interesting changes but isn't this what ALSR was meant to help to partially mitigate? ALSR can't fix this problem entirely as the executable needs to be discoverable somehow, it just makes it harder as the attacker has to put more effort into finding the correct memory location to patch. Other than this, good luck fixing as Windows isn't designed to segregate application memory space in this way when a user with local admin access is involved and continually security monitoring or reloading in-memory images is CPU intensive.
As noted previously, when a user with sufficient privelidges is compromised, you have a lot of problems and this is just an example of one. Pretty much why Best Practice dictates that no user should ever have such access on their normal account and instead have a separate admin account which they use on the occasions that they genuinely need to perform system administration. This doesn't make the problem go away, but it does help to reduce the chances.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
