Jump to content

Unresolved Security vulnerability exploitations

Recommended Posts

Hi there,

on one of our customer Windows Server 2019 machines with File Security 7.2 installed, I see multple unresolved security vulnerability exploitations per day:



What makes me bit nervous is, although the actions on these detections is "blocked" they don`t have the status "resolved". One can set resolved status manually. 

What does that mean? Do I have to worry about these messages?

The machine is a Windows Remote Desktop Gateway in a RDS structure.


Kind regards


Edit: The underlying process name is "System"

Edited by StotheR
Link to comment
Share on other sites

There isn't enough information posted to determine exactly Eset is detecting.

Incoming,Generic.Attack is something perhaps Eset has more knowledge as to source. All I can think of is an RDP brute force attack but I would assume Eset would post a like detection in the log.

Link to comment
Share on other sites

On 12/2/2020 at 9:57 AM, StotheR said:

Unfortunately the detailed view of that sort of message doesn't provide further information except that it says "not resolved"

Is the OS on this device fully patched?

In any case if this attack was CVE related, Eset would be indicating this. What is showing is a generic incoming attack. This could be again be a RDP password brute force attack, etc..

If the source IP address is always, I would create a firewall rule to block incoming traffic from it.

Also do you have group policies in place to prevent for example, RDP brute force password attacks such as disabling the logon being used after 3 unsuccessful attempts, etc.?

Link to comment
Share on other sites

Also this article might be a beneficial read:


Lock Down Your Remote Desktop Gateway Servers With CAPs and RAPs

As discussed in Chapter 8, I much prefer using Microsoft’s Remote Desktop Gateway over a standard VPN to provide external access to a Remote Desktop Services deployment. That being said, most organizations forget to tweak the two most important access features on their Remote Desktop Gateway servers after deploying them to tighten up security in the environment.

Those two features are called Client Authorization Policies (CAPs) and Resource Authorization Policies (RAPs). Put briefly, CAPs control who can log in and access the RDS environment through the Remote Desktop Gateway, and RAPs control what systems they can access once they are successfully authenticated.

By default, a Gateway’s CAP and RAP polices are wide open. Specifically, all Domain Users are granted the ability to attempt an RDP connection on ANY computer account in the domain! Definitely not a good security posture. Do not accept these defaults when setting up a new RDS environment – instead, change the CAP to point to only the group in Active Directory that contains users you want to allow to connect to the RDS collection. Likewise, change the RAP to only permit connections to actual RDS servers or user workstations, not every server that can be accessed via port 3389.

You can always create a different CAP/RAP pair (e.g. allowing RDS administrators to connect to RDS servers and another subset of servers on your network), but you should also consider layering in an additional level of security like Multi-factor Authentication for privileged account access.

For more information on how to set up CAPs and RAPs on your gateway servers, please review this great blog article written by my friend and fellow Microsoft MVP, Freek Berson.


Edited by itman
Link to comment
Share on other sites

Most of the source IPs differ. Every now and then one IP tries it multiple times. I also assume its some sort of brute force attack or a port scan. 

RAPs and CAPs are configured on the RDS Gateway.

Only thing that made me wondering was that detections in ESMC weren't resolved and handled automatically and one had the possibility to resolve it manually.

I just checked ESMC and since creation of my thread, detections of security vulnerability exploitation are handle and resolved automatically. 



Link to comment
Share on other sites

  • Administrators

It's an RDP brute-force attack on non-default ports. Normally the server should be put behind a firewall that would block this communication but if there's a web server running or clients need to connect via RDP from outside it may not be possible; in such case I'd harden RDP, e.g. by using 2FA.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...