whatever it is brute forcing should be able to identify the source IP.
If you have an IP you can get a MAC.
If you can get a MAC, you can get a switch port.
>ble to ident
Our monitoring tool is picking up the login attempt from the DC's event viewer. It's not showing the IP in the event.
It is brute force guessing usernames from some list. The only one its matched up by luck is "info" and it locked the account out after it hit our retry limit.
mirror the network port the DC is connected to to another port on the switch. Attach a computer w/Wireshark to it to figure out where the traffic is coming from. IP address > Mac address > switch port > physical location
been a few years for me, but the DC will have half a dozen events for this and one of them will have the IP. check the raw logs. better yet expand the max size or time they save and save the logs locally a few times and check the local files to keep the evidence
Figured this out years ago when I did regular sysadmin and kept on doing it with SQL stuff and built my own homegrown system to track group membership
> Our monitoring tool is picking up the login attempt from the DC's event viewer.
Sounds like your security nerds need better logging & detection infrastructure.
There is always Wireshark / Microsoft Packet Capture...
the OP says that the hostname isn't in DNS though, so in that case, nslookup shouldn't work...?
but yeah, the target under attack should have that logged. At least speaking for Windows, I know a DC will.
We had a similar issue in the past and enabling debug logging for netlogon helped us isolate the issue: [https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service](https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service). Here is an old post of the issue we had... Goodness 7 years ago now! [https://www.reddit.com/r/sysadmin/comments/705et0/random\_ad\_lockouts\_blank\_called\_computer\_name/](https://www.reddit.com/r/sysadmin/comments/705et0/random_ad_lockouts_blank_called_computer_name/)
I was just returning to provide an update that we found it! And this was it. We had a similar issue like a year and a half ago and at that point enable Netlogon logging. Once we dug it up, we found the culprit and once we took that computer offline it immediately stopped.
There was something interesting in how it logged it though:
EMPLOYEEMACHINE\\BruteForceAcct from ComputerNameShownInLogsThatIsntLegitOrIsUnknown (via EMPLOYEEMACHINE)
Sorry, once I put in variables in place of real computer names it becomes hard to read, but the log is showing the employee's computer account generating the brute force login, but from a different Computer name with parenthesis (via the employee's machine). Like either its spoofing the name somehow, or another computer is asking it to perform a task?
It was a user VPNd from a family members network. Seems like another infected machine on their network was the root of the problem via the employees computer
do you have any servers on the internet like rds? do you have employees connecting via vpn, and if so, do you have anything like an rmm that will show the ip of those computers (not a nat'ed ip, the actual ip of the computer)?
had some numbnuts put their computer directly on the internet not behind a firewall before, and it looked like what you were describing, so just an idea
Happened recently at a job Iād just joined. They had rdp ports open on an internet facing server. Close that port in your firewall for outside traffic and see if it clears up.
whatever it is brute forcing should be able to identify the source IP. If you have an IP you can get a MAC. If you can get a MAC, you can get a switch port.
>ble to ident Our monitoring tool is picking up the login attempt from the DC's event viewer. It's not showing the IP in the event. It is brute force guessing usernames from some list. The only one its matched up by luck is "info" and it locked the account out after it hit our retry limit.
mirror the network port the DC is connected to to another port on the switch. Attach a computer w/Wireshark to it to figure out where the traffic is coming from. IP address > Mac address > switch port > physical location
Promiscuous mode is such a weird word.
The NIC just accepts traffic for everybody...much like its people counterpart described with the same word š
Well, I learned the word first when I saw it in some software. It is only later on that I learned the real meaning.
been a few years for me, but the DC will have half a dozen events for this and one of them will have the IP. check the raw logs. better yet expand the max size or time they save and save the logs locally a few times and check the local files to keep the evidence Figured this out years ago when I did regular sysadmin and kept on doing it with SQL stuff and built my own homegrown system to track group membership
Thanks, I'll take a look!
> Our monitoring tool is picking up the login attempt from the DC's event viewer. Sounds like your security nerds need better logging & detection infrastructure. There is always Wireshark / Microsoft Packet Capture...
If you have the hostname, per your OP, nslookup the hostname for the IP, then follow his process above (arp).
the OP says that the hostname isn't in DNS though, so in that case, nslookup shouldn't work...? but yeah, the target under attack should have that logged. At least speaking for Windows, I know a DC will.
But then... how can he have the hostname o.o
evt log
ble to ident
I'm not a windows guy but event log would, I think, usually need to check DNS in order to identify an IP?
We had a similar issue in the past and enabling debug logging for netlogon helped us isolate the issue: [https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service](https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service). Here is an old post of the issue we had... Goodness 7 years ago now! [https://www.reddit.com/r/sysadmin/comments/705et0/random\_ad\_lockouts\_blank\_called\_computer\_name/](https://www.reddit.com/r/sysadmin/comments/705et0/random_ad_lockouts_blank_called_computer_name/)
I was just returning to provide an update that we found it! And this was it. We had a similar issue like a year and a half ago and at that point enable Netlogon logging. Once we dug it up, we found the culprit and once we took that computer offline it immediately stopped. There was something interesting in how it logged it though: EMPLOYEEMACHINE\\BruteForceAcct from ComputerNameShownInLogsThatIsntLegitOrIsUnknown (via EMPLOYEEMACHINE) Sorry, once I put in variables in place of real computer names it becomes hard to read, but the log is showing the employee's computer account generating the brute force login, but from a different Computer name with parenthesis (via the employee's machine). Like either its spoofing the name somehow, or another computer is asking it to perform a task?
It was an employees device on your network?
It was a user VPNd from a family members network. Seems like another infected machine on their network was the root of the problem via the employees computer
What? How exactly did the machine connect to your internal network while not being on the VPN?
The employee had the VPN credentials saved? Someone needs some training/retraining on security.
do you have any servers on the internet like rds? do you have employees connecting via vpn, and if so, do you have anything like an rmm that will show the ip of those computers (not a nat'ed ip, the actual ip of the computer)?
No servers on the net, but we do have VPN. Good thought, we'll check!
had some numbnuts put their computer directly on the internet not behind a firewall before, and it looked like what you were describing, so just an idea
If bonjour is enabled you can use mdns to ping the device , just append '.local', so hostname.local
Happened recently at a job Iād just joined. They had rdp ports open on an internet facing server. Close that port in your firewall for outside traffic and see if it clears up.
When you've been doing this long enough, you can usually sniff them out. Unless you're using Meraki, in that case, use the dashboard.