5

One of our servers (running RdpGuard) shows multiple failed attempts from specific users' machines (3 to be exact) and I can't figure out what is causing them. One user is local and two are remote using VPNs.

Today there's a pattern in the attempts.

The three IPs are 192.168.1.11, 192.168.1.45, and 192.168.1.85

The pattern goes as follows:

Failed attempt from: 192.168.1.48 (remote vpn)
Failed attempt from: 192.168.1.48 (remote vpn)
Failed attempt from: 192.168.1.11 (remote vpn)
Failed attempt from: 192.168.1.11 (remote vpn)
Failed attempt from: 192.168.1.85 (local)
Failed attempt from: 192.168.1.11 (remote vpn)

These attempts happen every ~4-5 minutes in that specific order today.

I've run multiple malware/rootkit/virus scans which returned no results.

UPDATE 1:

The RDP attempts are now coming from random machines inside the local LAN. Servers and workstations are affected.

UPDATE 2:

So after a bit more reading I was able to find out about the netlogon.txt file (on the primary DC). From there I was able to determine the origin and destination of the attempts of all these RDP attempts. I ran procmon on the origin machine and matched the event from the netlogon file (on the PDC) to the correlating event on the destination machine. I took the source port used which was logged in the event viewer (security) on the destination machine and matched filtered procmon using that port num. That gave me the process/PID of the culprit which was a network management service used by "Advanced Monitoring Agent"/RMM which is an MSP software by solarwinds (I looked up the PID in Task Manager).

So for some reason the MSP agent was trying to RDP using the guest account. I have went ahead and uninstalled it from all the local users machines and servers. I have left it on the users machines at remote sites as there are no attempts coming from them (due to them being in a different subnet I believe). I have also removed the VPN users from the domain and they now access internal files using 2xRDP.

Improve this question
3
  • I'd look for any auto update routines that are starting on May 1st and use RDP.
    – Tom K.
    May 2, 2018 at 12:43
  • @TomK. Sorry for my ignorance but should I look for anything specific? I don't quite understand why workstations would need remote access to perform any updates. Is it a windows thing (WSUS)?
    – mend0k
    May 2, 2018 at 15:14
  • WSUS might be a possibility. Why update routines? You said that this started yesterday, so May 1st. Some auto update routines start on the first of each month. That's why I'd look for set dates in any software that has short update cycles. I might be off though, that's why this is just a comment.
    – Tom K.
    May 2, 2018 at 15:29

2 Answers 2

Reset to default
2

If it is still happening every 4-5 minutes, I would go to one (or all) of the three hosts and run sysinternals procmon (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) to capture system activity.

You'll get an awful lot of data, but if you check the network aspect of the tool, you should be able to look for connections to your server on TCP:3389.

Procmon data should be able to tell you what process is making the connection and you should then be able to follow that back to the source.

If these connection attempts are happening at regular intervals, I would also check Scheduled Tasks (or use CLI schtasks.exe) and review what is listed there.

Improve this answer
3
  • Thanks for the response. Port 3389 has been blocked already (all ports have been blocked except for a few). I was unable to find anything with Procmon. I ran it on the server(s) being attacked. Though I was able to see legitimate RDP connections in procmon.
    – mend0k
    May 24, 2018 at 16:54
  • My suggestion was to run the analysis on the hosts attempting to connect to the server. If you are blocking 3389 at the server, then that avenue is probably blocked, but I think you'll need to dig into the connecting clients (assuming you have access) to learn more. On the server side, maybe the error code accompanying the "Failed attempt from" messages will indicate why. It could be using bad credentials or connecting in a way that your RDP server doesn't support.
    – cglidden
    May 29, 2018 at 17:25
  • Thanks - I'm marking this as the answer as I wouldn't have been able to figure this out without being led to Procmon.
    – mend0k
    Jun 1, 2018 at 18:14
2

Please check windows security logs and look for login attempts. You can filter by event codes and look for login type 10. This is an RDP login. It could be that some service in some computers might be trying to access the drive with incorrect credentials.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .