Sometime back, I chronicled one of the most infamous “hacks” that ever happened. A gentleman named Jason Cornish brought the Shionogi Pharmaceutical Company to its knees. In a nutshell, he and his friend saw that things were going bad for them and decided to take revenge. They altered an account to allow themselves access from outside the company’s network, got in, and deleted several dozens of systems (all of them were VMs). Effectively, they destroyed the company’s ability to conduct business for several days, which resulted in almost a million dollars in lost revenue.
Understanding the process
Sadly, this could have been avoided. In this blog, I intend to demonstrate how using some built-in tools will help. First, I’m making two big assumptions here. One is that we have a good Change Management system in place. Someone has to request something, it has to seek approval through a board, and once approved, the change is made. My second assumption is that once a change is made, we have a validation process, and this is where AD native auditing comes in.
This screen shot is of the Active Directory User OU in my test lab.
I’ve got Kevin Riley highlighted because I’m going to make him a member of the “Domain Admins” group. This is going to be a big red flag, and I’m going to get an e-mail regarding this event.
- First, we have to understand how the process might work. When someone is added to the Domain Admins group, an approval should be passed and the IT team should get a notification that Kevin now has admin rights. Most ticketing systems will allow you to build in an “Approval” function. It doesn’t have to be anything more complicated than a pull down that allows the individual in charge of approving it (and incidentally, only that person has the rights to add his or her names to the box) to do so. Anything associated with this ticket (e-mails, etc.) becomes a part of the ticket. This enables us to see what happened at every step along the way and to ensure the process has been adhered to.
- The pertinent questions are as follows: “Does the approval process really help protect against unauthorized changes? How about protection from a rogue administrator? This is where change monitoring comes in. In the Kevin’s case, the function is governed by the process. However, if someone just gave him the rights (accidentally or intentionally), I want to know about it.
- To understand the process, we have to look for events. Whenever anyone is added to certain groups, such as Domain Admins, a key event is triggered. The magic Event ID you’re looking for is 4732. These get logged on just the Domain Controllers, so I’ll go to the Domain Controller.
- Now that I know that, what do I do with that piece of information? First, I need to understand that Domain Admins is a security group. In theory, every time I add someone to this group, that event will be generated.
However, it doesn’t do me a lot of good if I don’t have a way of watching it.
Building alert inside the Domain Controller
I could buy insider threat detection software that would do this for me, but I prefer building my own Alert inside the Domain Controller.
To do that, proceed through the following:
- Go to Start > Accessories > System tools > Task Scheduler.
- Click on “Create a Basic Task.”
- Give the task a name and describe what it’s supposed to do (so if you get hit by a bus, someone knows what it does).
4. Specify a trigger, in this case, an event.
5. Fill in the information you need.
6. Choose the action to be performed. In this case, I want it to send me an e-mail.
7. Enter the required information. I’m keeping it rather simple.
Now, the single major objection I hear concerning doing this (or any kind of real-time alerts) is that it generates too much garbage, and it does. However, it all boils down to this: If you’re expecting the change, it’s safe to ignore it. If you’re not, you better ask questions.
There’s a lot of commercial software that will do the same thing for you and take a lot of the tedious work out for you. This makes investing in one of the commercial software packages well worth it.
Another thing you should watch for are inactive accounts. Most people would consider anyone who hasn’t logged on in 30 days inactive. Asking why there isn’t any activity on an account should start leading you in the right direction. Let’s look at some possible answers:
- The person is no longer with the company and somehow you missed deactivating them.
- They’re out on maternal leave, sick leave, vacation, or any number of reasons and you missed this somehow.
- It’s a service account (you should have a list of your service accounts—the fewer, the easier for you to keep track of).
- Something else is going on.
Using PowerShell script
You can use a simple Powershell command run from inside your domain controller:
Search-ADAccount -AccountInactive -TimeSpan 60 -UsersOnly | Where-Object { $_.Enabled -eq $true } | Format-Table Name, UserPrincipalName | Export-CSV FileName.csv -NoTypeInformation
You can change the number of days to any number you need.
Notice that I’m having it send me a report as a CSV file. This becomes useful for auditing purposes, not to mention justification of anything I need to do to that account (like opening a ticket and deleting it).
Deploying professional tool
Instead of using PowerShell scripts, you can deploy a professional tool to get reports to your e-mail. In the following screenshot (I use Netwrix Auditor for Active Directory), we see a change made to the Domain Admins group, and another one made to Kevin Riley’s account:
Another report shows users who haven’t logged in for a long time, and their accounts have been disabled:
This also helps demonstrate to auditors that we’re taking action to protect the network against unauthorized access.
Would these methods have stopped Jason Cornish and company? Maybe. One thing is certain: There is a greater probability they’d have been stopped well before the hack went down if some simple safeguards had been in place.
