Posted
Leveraging the Active Directory and ThreatConnect integration to help automate security processes
ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.
This post is the first in a series focused on integration scenarios between ThreatConnect and Microsoft Active Directory that customers can leverage to help automate security processes between cyber threats and incidents in ThreatConnect, and adjusting security policy or enforcing behavior with Active Directory users.
We’ve observed an issue which has plagued enterprises for some time now, and the longer it remains unaddressed, the greater the vulnerability to the organization. Microsoft Active Directory (AD) has been an indirect target for years, and only now is there awareness of the issue among many CIOs and CISOs which has been reaching critical mass. When a phishing attack and or any other account compromise occurs, hackers want to gain credentials to exploit infrastructure. Simple fact: the average Active Directory user has more than 100 account entitlements making compromise of an Active Directory account highly critical. These compromises, of course, can lead to damaging breaches threatening an organization’s livelihood.
Most SOC analysts concentrate tactically on identifying a phishing email and neutralizing, blocking the URL and source. However they do not assure that the login, and especially the password, have not been compromised. This is due to a variety reasons, such as having to log into the AD directory, not knowing the infrastructure layout and not having proper permission to make changes. When an attack has taken place, ThreatConnect’s orchestration capabilities can automatically connect to AD and gather victim information — such as email address or any other key attribute — and then change the user’s account policy so at the next login they will be required to change their password. This type of rapid response enhances the overall security posture of the organization.
This Playbook is a straightforward example of forcing a user to reset their AD password after being flagged in ThreatConnect as a victim. When an analyst searches for the victim name in ThreatConnect, she can then add add the tag, for example “flag”, and this action triggers the playbook to run in the background. The trigger drives the logic to query Active Directory and pulls email address and other attributes in necessary to populate the info into the victim’s asset information within ThreatConnect. The advantage being that over time ThreatConnect can report which employees were part of which cyber attacks related to this specific phishing email.
The master Playbook is illustrated below. The Victim Trigger drives the subsequent steps after a tag is applied. Next, there are two Playbook Components: LDAP Email Query (in orange) and the LDAP Password Reset 1. These reusable Components can be leveraged in other Playbooks ThreatConnect users may want to deploy.
The above integration is bi-directional with LDAP/Active Directory. It will also send a subsequent SLACK message to remind the user that they will have a password reset at their next login.
Below is the Playbook Component which will query LDAP/Active Directory for specific attribute information. In this Playbook, we will query the LDAP/Active Directory email info for the victim. We then convert it to String data and post the email info into ThreatConnect.
Below is the Playbook Component which will change the LDAP/Active Directory specific attribute called “pwdLastSet=0”. By setting it from (1) to (0) zero will force the user to change their password at next login. It will also send a SLACK message at the end of the playbook of the upcoming password reset.
Below is the result of of the email information queried by ThreatConnect against LDAP/AD for the needed information as well as any other key attribute information or relevant Asset information.
The example below demonstrates the change of the Active Directory attribute to force the user to change their password at the next login.
In the next blog post of this series, we’ll show how the process can begin with the receipt of a phishing email where we use information in the email to query and affect changes in Active Directory for a number of users, and how that data can be reported in a ThreatConnect Dashboard.