Really, it’s not just me saying that Active Directory is the crown jewel. It actually them, the hackers, that de facto target the active directory in almost every advanced attack. They look for domain credentials and administrative accounts, they practice domain reconnaissance, privilege elevation, targeted attacks against the domain controller and more. Their motivation is similar to terror. For example: produce widespread fear, obtain recognition and attention of media, steal money, damage facilities and functionalities. This is why it was not surprising to learn about the QakBot Trojan causing a mess.
This malware is now back in business not only by renewed distribution but also making a lot of noise by locking accounts on the active directory. (You can read much more detail about it in the article mentioned above.) I’d like to focus on what CAN be done to detect this creature and prevent its chaos.
Here are the main “things” QakBot aka PinkSlip does:
- Spies on users, steals their information and.... takes their money
- Distributes itself maliciously through network shares
- Hides. It turns off the security software on endpoints and creates mutations of itself
- It makes a mess. A recent discovered capability. Think of this as a type of DDOS attack - it massively locks users out of their accounts. There is a way to unlock users but there is a better way to deal with it and it is to prevent this evil actions
Essentially, the article mentions the frustration associated with this piece of software: “QakBot is notorious for its capability to persist on infected machines. This, combined with the malware’s Active Directory lockout capabilities, makes it especially frustrating to detect and remove in enterprise environments.”
Now, that we know that it is like Batman's nemesis The Joker, we understand the problematic situation and we realize that traditional solutions such as end point protection may fail to identify and stop it, let's mention a few main things that can be done.
4 ways to prevent QakBot chaos
- Use a contextual password expiry control
My suggestion may read as extreme but it’s rather simple to do and operate. Get rid of your password expiry policy - the one which makes users change enumerate their passwords while their password is actually strong. Make it smarter and manage this based on contextual and behavioral data which is learned for every entity.
For example force password change only when one or more of the following conditions are met:
- when user risk score hit a certain threshold
- when password discovered to be weak
- when user account involved in an incident.
Continuous monitoring and detection of locking endpoints. You need insights not only to the entities that are locked but where they were locked from. Easy. Quick, scheduled or on demand report will give you immediate value.
Lockout policy suffers from a fundamental design failure that doesn’t meet the need of current era and denial of service attacks. The built-in lockout mechanism in directory services is static and relies on a fixed number of authentication retries. As we all know, static fails the dynamics of users and networks. Solutions which protect against DDOS identified this a long time ago, and now they all provide dynamic thresholds. In this case you may think, OK Mr. Smart, how can this be achieved if the domain services aren’t that smart? As simple as it is, it gives our organization some level of protection from brute force, we can’t stop using this mechanism. However, now there are solutions that rely on a behavioral mechanism, they don’t use just a simple count and add an additional layer of advanced decision based on the user location and historic baseline.
OK so now you probably say again, Yes Mr. Smart, how?!? Well this one is really easy. If this creature (what is it anyway? Worm, Malware, Trojan, Bot, Virus, all of the above?) needed to provide a proof of its identity everytime it tries to distribute itself via shares, authenticate, do activity on behalf of an account or else it is blocked, then this problem is solved. Want to only raise the awareness? Send a verification email instead.
To sum this up, although this blog touches on QakBot, this is just an example and this general concept that can help in similar scenarios.
And one last thing, did you know that Preempt offers a policy to help users to unlock themselves without IT intervention?
You can watch a quick video learn more or request a demo where we can show you how this works in action.