The Insider
The Beginning
It all started with account lockouts on Active Directory. At first, I didn't have to deal with it, my manager did. Once a day, sometimes twice, they would log in to the server and unlock accounts. It seemed to be coming from nowhere and was random. Sometimes it'd be first thing in the morning, other times the first time it would happen for the first time in the afternoon. Even more odd, it wasn't all accounts. My account, for example, didn't get locked out for months.
After a while, I was asked to help. It was a lengthy process going through each account and unlocking them manually, especially as the number of accounts that were locked out started to increase. From a dozen or so, to a few hundred. Eventually, I found a command line tool someone wrote that would get a list of all accounts and unlock them. What took hours now took a couple of minutes. But why were we even having to do this?
From Active Directory administrator to researcher
What I probably looked like to my boss.
But it's not terribly far off either. I pulled out a couple of books and put them on the desk. I was flipping through pages of one book while skimming another. It was great. After a while, my account was getting locked out too. But how did they miss my account at first? What was different from my account and the other accounts?
That was part of the answer - my account was different. It was new; only a few months old at the time and wasn't in the list of accounts that were being locked out daily. But after a while it did start getting locked out. So how did my account get included?
Almost out of a movie, half the answer was in one book and the other half in the other book. The answer? Null sessions. At the time, a configuration change was needed to integrate with an older version of Windows Server. This configuration change opened up null sessions.
What are null sessions? From archive.org:
A NULL session connection is an unauthenticated connection to an NT/W2000 machine. Gaining NULL session access to an NT\W2000 system is the number one method for hackers to enumerating information about an NT\W2000 machine. From a NULL session hackers can call APIs and use Remote Procedure calls to enumerate information. These techniques can, and will provide information on passwords, groups, services, users and even active processors - (How is information enumerated through NULL session access, Remote Procedure Calls and IPC$? (Wayback Machine))
And this is what seemed to be happening. Users were getting getting locked out, but how? They were seemingly getting enumerated every so often, which would explain why my account wasn't getting locked out. But I had to prove it.
The Switch from Defensive InfoSec to Offensive
When I started my interest in Information Security, I was on the "blue" side, though it wasn't called blue at the time. Incident Response, or IR was one facet. I in some ways filled that role, or I tried at least. But like this photo, what followed was a mix of what is called blue and red today.
Though I didn't realize it at the time, I made a career switch when I switched from defensive to offensive researching this null sessions issue. I had to prove that it was in part null sessions that were the cause. There was one program, enum.exe, that was used for exploiting this issue. Linux systems (like Kali), have a port of it called enum4linux. I downloaded a copy of enum.exe and tried it. Pages and pages and pages of data was pulled down. I had the password policy. I had the user list. I had it all. All said, it was about 90 pages pages-worth of data that I got. But I got something else too - I got bitten by the offensive bug.
Who?
At this point, my theory was that whoever this was, was using enum to abuse these null sessions to get a list of users and then using brute force attacks to lock out accounts. We could keep unlocking accounts everyday with the tool that I found, but we had better things to do and we certainly couldn't keep it up with asking users to hang on in the morning while we unlocked their account. They had their own work to do.
I set up Snort sensors and wrote a couple of rules to detect this behavior based on the research I did of null sessions. And it worked. Mostly. I could see when things were happening but not exactly what. But it was enough. I presented what I had to my management and they had suspicions of who it might be - a user that was disgruntled with the organization. And we had no way to prove it.
Danger Ahead
As we tried to find ways to gather evidence against the person we thought it might be, a hallway conversation that probably shouldn't have happened was in some ways the answer we were looking for. I took a break from combing through logs and my boss caught me in the hallway to ask me if I was making any progress. I noticed that someone was listening to the conversation and then scurried off when they saw me looking their direction. It wasn't the person we thought was doing this, so why were they interested? The conversation finished and I went on about what I was doing.
Putting the Puzzle Together
After that conversation and weeks of work, it all stopped. No more lockouts. My Snort rules stopped alerting on activity.
What I think happened is the person that was listening to that fateful conversation in the hallway was a friend of the disgruntled user, because the person that we thought it might be just stopped showing up at the same time as the attacks stopped. Coincedence? Maybe. But it was too much of a coincedence for me.