Jump to content

Need more information on protocol mismatch detections


SEV0218

Recommended Posts

I'm getting a large number of "RDP communication over nonstandard port" with a wide range of parent processes and commandline entries as well as inconsistent ports. Some examples include process of dns.exe on port 53 (making it sound like RDP over DNS), Java.exe on port 80, and even port 445 with no process. It will occasionally give me the commandline that triggered the detection, but most of the time I get nothing more than what I gave in my examples.

Is there a better way for me to dig into this? I'm kind of coming up empty on most of my usual resources like MITRE and various threat DBs.

Link to comment
Share on other sites

  • ESET Staff

@SEV0218 For rule "Protocol Mismatch - detected RDP communication over non-standard port [E0517]", it is important to identify if it is inbound or outbound events causing the detections.

You can see the same issue you are speaking of has been addressed in this post here: 


Its very likely that you have ports exposed to the internet, and public IP Addresses are performing port scans of your public IPs and testing what is hosted on each port (AKA Service Scan).  This can lead to inbound connections on ports like DNS (53) where the port is tested to see what is on.  This will lead to RDP communication being seen on port 53 and other ports, as they are being tested to see if they host RDP on those ports.  Its likely the port scans are also working to see if other services like SMTP, DNS, SMB, etc... are on any ports visible to the public.

I highly recommend auditing what ports you need exposed to the internet and work towards closing any ports which should not be exposed to the internet.  For ports you cannot close, you should work towards restricting who and what can access those ports.

Link to comment
Share on other sites

So simply attempting to establish a connection on a port will trigger these alerts? Even if the connection was incomplete?

18 hours ago, itman said:

The systems showing the dns.exe process were domain controllers, so it's not unusual. These systems specifically look to be triggered by the SIEM, however.  The problem I have now is that there doesn't seem to be a way to write an exclusion for the source IP that triggered the alert, only the local application.

 

18 hours ago, JamesR said:

I highly recommend auditing what ports you need exposed to the internet...

All the alerts I'm getting are from internal IPs, none are external. We have very few external ports open and those that are have very specific routing.

Link to comment
Share on other sites

  • ESET Staff
23 minutes ago, SEV0218 said:

All the alerts I'm getting are from internal IPs, none are external. We have very few external ports open and those that are have very specific routing.

Since it is from internal IPs, you should verify if those IPs have Vulnerability scanners or software which may be port/service scanning (some software proactively does silent services scans on the network to identify remote machines and it can be hard to identify which software is doing this).

 

25 minutes ago, SEV0218 said:

So simply attempting to establish a connection on a port will trigger these alerts? Even if the connection was incomplete?

Its more than just the TCP handshake.  Its the TCP handshake followed by the initial request of RDP or SMB which ends before any real info is transferred.  Service based port scans send the minimum amount of information required to attempt and identify what service may be hosted on a port.

 

If you find these to be benign detections, you can use the following template to build an "Advanced Exclusion" for these:

<definition>
    <operations>
        <operation type="TcpIpProtocolIdentified">
            <operator type="or">
                <!-- exclude specific IPs -->
                <condition component="Network" property="IpAddressV4" condition="is" value="192.168.2.123" />
                <condition component="Network" property="IpAddressV4" condition="is" value="192.168.2.124" />
                <!-- exclude specific subnets -->
                <condition component="Network" property="IpAddressV4" condition="isnot" value="192.168.5.0/24" />
                <condition component="Network" property="IpAddressV4" condition="isnot" value="172.16.29.0/24" />
            </operator>
        </operation>
    </operations>
</definition>

Note: To make an Adv Exclusion: While creating an exclusion, and on the "Criteria" section, click the "Advanced" button in the top right of the GUI.

Link to comment
Share on other sites

Great info. Thanks for the direction!

Is there a place where I can veiw a detection where it will give me similar terminology as the advanced exclusions? I would like to better understand the formatting/syntax of the exclusion language. My fear is that I will inadvertently make too broad of an exclusion.

Link to comment
Share on other sites

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

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