We have had some random bulk lockouts of accounts over night a few times lately.
Netwrix Account Lockout Examiner shows them as locked out however it only shows the workstation name as Windows7.
Can someone tell me if this is a generic name for a Windows 7 machine that Netwrix Account Lockout Examiner is unable to tell us the correct name of? or if it's actually the name of the machine?
We have been experiencing the same situation over the last few days. Windows7 as the workstation name, yet there is no Windows7 on the domain that we can find.
We are seeing the same exact thing in our org. In addition to "Windows7" being the computer name causing the lockouts, we are seeing "FreeRDP" and "debian-8-32bit" locking out the same accounts that are being locked by "Windows7". None of these computer names are resolvable.
The accounts being locked out are generically named accounts, like "Support" or "Scanner" or "Monitor", which lead me to believe its some kind of malware in our environment that is trying various generic account names.
If anyone has more info on this, please respond to this thread.
We are seeing the same exact thing in our org. In addition to "Windows7" being the computer name causing the lockouts, we are seeing "FreeRDP" and "debian-8-32bit" locking out the same accounts that are being locked by "Windows7". None of these computer names are resolvable.
The accounts being locked out are generically named accounts, like "Support" or "Scanner" or "Monitor", which lead me to believe its some kind of malware in our environment that is trying various generic account names.
If anyone has more info on this, please respond to this thread.
This is interesting, we are also getting hammered with Windows7 & FreeRDP stations (no debian-8-32 though). There is a product called "RDPGuard", I am thinking of setting that up (trial software) on a couple PC's as HoneyPots that perhaps can log the IP address from these stations attacking them.
Well the last round of heavy intensive hammering was from the far east (221.203.142/24) but I certainly don't want to brand the entire subnet as hostile and there are plenty of global attempts that make it irresponsible to accuse one subset of offending traffic as the point of all problems. That being said, this time, it is (was) these IP's that were hammering for RDP & SSH, so I will block the class C subnet for a month. Next time I'm sure it'll come from another point on the globe. Unfortunately, I'm located in a place where there is excess travel and global access back to a variety of services is an expected service. So the concept of "banning" ranges long term isn't an option and we have managed to reduce our exposed footprint quite a lot with various gateway features and security measures.
Briefly, but now seeing a lot from 31.44.191.x & 91.186.8.x . I think the reason the names are the same is it is some canned script tool that no one bothers to change when they run it. I am still on the trial version of this RDPGuard; but the honeypot idea does manage to capture who is trolling, if I could just find a way to populate the firewall easy via the software's logging. It's not cost effective (realistic) to buy software like this for a mass amount of machines.
Thanks for the update - I didn't see any instance in or out of the IP ranges on the original post. I set Netwrix up to alert on any change to the account that they're attempting to access, and am running wireshark on the targeted DC. I managed to capture one hit, so now at least I have a suspect client. Starting that process over to see if I can confirm those findings. I'll do another search for the batch of IPs you just posted. I'd tend to agree that it is a canned bit of script based off the commonality of the accounts & workstation names. If I can confirm my findings, I'm going to get in touch with my CERT and ship them the hard drive. I'm monitoring this thread, and will post any updates I have.
@jtb2035 Unfortunately not, and monitoring packet captures is not my idea of good time. I caught it once from a workstation, and hoped to catch it again. SInce I haven't, I went ahead and had that workstation wiped as a precaution, but I'm still seeing it in the environment. I opened a case with Netwrix since multiple people were reporting the issue, and their reply was "Netwrix only pulls what it sees from the Windows Logs". Find anything useful / new in your environment?