A client contacted me recently concerned that someone was locking out user accounts, but the client couldn’t see the source of this activity in their SIEM. Had it been implemented properly? Was there a bug or problem with the system? Maybe the logs weren’t being parsed properly. Inquiring minds want to know!

I like a good mystery, so I got straight to work. The client urgently wanted to identify the source of what was suspected to be either a brute force attempt or denial of service attack against their user base. They pressed me to identify the IP addresses, so they could block them on the firewall.

I quickly discovered that their SIEM was properly configured and healthy, yet I still couldn’t find the source IP addresses by searching the logs. I verified that they were collecting logs from all the relevant Active Directory, Active Directory Federated Services, Proxy servers and firewalls.

Here is where I discovered several architectural issues with the client’s environment. Along with a twist.

Every good mystery should have a twist.

It turns out that my client has some fundamental architectural issues which needed to be addressed. They were running a rather old version of ADFS, as well as Windows Operating Systems. Therefore, they were unable to turn on the level of logging that would have included a true source IP address. It was going to take some time to do the necessary upgrades, so I pointed this out as something they should address as soon as possible. I moved on with my investigation. Perhaps I could get what I needed from firewall logs. Nope. During the logon failures, I eliminated all the traffic except for the traffic going to and from Microsoft. I had a look at O365. That was a dead-end, as well. They were tracking all activity in O365, but their subscription level did not include logging logon failures. Yet another note for consideration, Premium AD.

Wait a minute.

I had looked at the packet captures through their NetMon tool and had eliminated all the traffic except for Microsoft traffic. That was it, the twist! The accounts were being locked out, but the traffic was coming directly from Microsoft. Blocking the traffic on the firewall was not going to be an option. I doubled back and looked at the client’s O365 Tenant again. Eureka! There it was, POP3 and IMAP were enabled and not being used. I did some tests using bad passwords and POP3. Turns out I could duplicate the lockout and the log activity my client was seeing. I recommended they disable POP3 and IMAP and the lockout activity stopped. Success!

High fives complete, I made some additional recommendations and helped them put additional controls in place that addressed other gaps I discovered along the way. I had a happy client who was a little more secure. OK, I’ve shared enough of the salient points, so I will leave it there for now.

Until next time, happy hunting!