Microsoft Advanced Threat Analytics - your first step on the journey.
What is the problem that Advanced Threat Analytics (ATA) is trying to solve?
ATA is seeking to detect and alert you to attacks from inside your network; it will find abnormal Active Directory user account behavior, monitor it and alerts you if it finds something amiss. This is the first toolset that I would deploy in my environment. I even deploy this before Azure AD.
ATA does not fit the usual Microsoft profile in that the database is a MongoDB and the website is not built on IIS.
In most companies, we login to our on-premises AD with a username and password. Once I login successfully I get a Kerberos ticket and with this ticket, I access resources throughout the organization. In my experience, in 99% of companies, the user's movement and actions are not monitored in terms of behavioral patterns once the login has successfully happened, sure we monitor file and folder access but not what the user is doing in terms of an attack on the local machine, or other systems.
In a previous post I wrote (I'm safer on-prem, Right?) I went into a reasonable amount of detail on the process of attacking an endpoint and capturing a stored hash. The advice I gave was to deploy ATA to help you identify nefarious user behavior.
This is not a complex product to install or manage and should be first on your “Data driven security project list”.
· The “Center” is a dedicated server that receives the data from gateways
· The “Gateway” can be a dedicated server or a “Lightweight Gateway” installed directly onto your Domain Controllers (DC’s)
· It builds a behavior pattern over time (ideally 30 days) but works straight away
· It will identify unusual activity and when it discovers behavior that is suspicious it will tell you all the users that have logged onto that machine, and all the machines that the user in question has logged onto.
ATA looks to build out a behavior profile pattern, and when it identifies that a user has been compromised, it records where a user has been, on what machines and where a likely attacker is going. The first question you may ask is how? Aren’t there thousands of different types of attacks? Yes, there are, but they all follow three stages, it’s the behavior in these three phases that ATA is looking for.
When we take a typical use case of a user, enabling a macro or downloading something dangerous through email a three-phased approach is taken once the initial payload has been delivered. The attacker starts with a “Reconnaissance” phase, trying to learn anything useful about your environment. They are trying to find out your IP addressing, your DC’s, default gateway etc. At this phase, a Pass-the-Hash style attack may be used to gain the username and password. The attacker then usually moves onto other resources to traverse the network, usually referred to as “Lateral Movement”. When on a high-value target, they will then move onto the last phase of “Dominance”.
What are the design and deployment phases likely to look like?
ATA has three roles;
1. The center, this is the brains of the solution and it acts as the collector from the gateways.
2. A Gateway, this role is deployed to a VM and uses port mirroring to get your DC’s to send information to it.
3. A Lightweight Gateway, this role is deployed directly to your DC (every DC) and it sends information to the center (you only need to deploy either a gateway or a lightweight gateway).
The project to deploy ATA depended on your domain structure. You can only have one ATA environment per forest. ATA consists of at least one VM for the center and you could, in theory, deploy all lightweight gateways to your DC’s.
Some points for the project;
· You need a dedicated VM for the “Center”
· You could just use lightweight gateways on your DC’s and not have to deploy gateways or enable port monitoring
· You must allow for the ATA memory and processing on your DC’s, and that could involve adding resources to VM’s or resizing cloud-based VM’s.
· There is a sizing tool on Technet that works out how much traffic is taking place on your DC’s
· The lightweight gateway has silent installers and could be deployed to your DC’s from a tool like SCCM/LANDesk
· There are no rules, custom tuning, or any of the usual monitoring tool nonsense we usually have to deal with
· The gateway option requires port mirroring, an extra VM, and slightly more effort
· The gateway/port mirroring option is harder to discover from a hacker’s perspective
· If you are already breached ATA will not profile this traffic as normal while it's building its pattern
· Installing the center and 10 lightweight gateways would take no more than a day
· There is no dependency on AAD, you can deploy all of this to on-premises AD only.