Jump to content

Archived

This topic is now archived and is closed to further replies.

CraigF

Increasing Botnet.CnC.Generic detections

Recommended Posts

For the past week or two we've received Network Attack Alerts relating to Botnet.CnC.Generic detections across all our (Australian based) clients.

According to VirusRadar (https://www.virusradar.com/en/home/world) this is currently the most common threat detection, yet I've been able to find no information about it. The detections are on inbound traffic from a small number of IP addresses. We're seeing them mostly on port 443 (as that is one of the few ports they have open), but we have seen it on port 2222 (ESET ERA) also.

It's not clear whether ESET File Security is taking any action to block these threats.

These are some of the source IP addresses we're seeing:

193.188.22.187
185.156.177.235
185.153.199.3
141.98.81.66
45.136.111.112
45.136.108.68

My understanding of CnC threat traffic is generally triggered from the infected machine so would be outbound rather than inbound, so I am somewhat confused by these notifications .

Can anyone shed any light on how ESET detects a "Botnet.CnC.Generic" threat so I can determine whether this is something we need to respond to (e.g. is it just based on the source IP address?)

Also, is anyone aware of CnC servers that would be spraying out traffic to web hosts?

Share this post


Link to post
Share on other sites

Generally it's a detection of brute-force attacks. Every such attempt is blocked even if you see "Detected" in logs.

If you google those IP addresses you'll typically find them listed at abuseipdb.com as a recent source of attacks.

Share this post


Link to post
Share on other sites
11 hours ago, CraigF said:

We're seeing them mostly on port 443 (as that is one of the few ports they have open)

This is one of the worst ports to have open on the WAN side of the gateway.

Any open port on the WAN side of the gateway needs to locked down by restricting its use to any specific devices that require this. Ideally all ports on the WAN side of the gateway should show stealth status which in effect makes your gateway invisible to any external attacker.

Share this post


Link to post
Share on other sites

Hello, 

I noticed, that a Exchange 2013 Server (I think with CU 22) has approx. 500-1000 Attacks in Dezember with ref to Botnet.CnC.Generic  on Port 443

 

Share this post


Link to post
Share on other sites
7 hours ago, Joe-ESET2016 said:

Hello, 

I noticed, that a Exchange 2013 Server (I think with CU 22) has approx. 500-1000 Attacks in Dezember with ref to Botnet.CnC.Generic  on Port 443

 

Assuming you've already examined the border edge of your gateway and verified that port 443 is in stealth or closed status, I would recommend the following.

Create a firewall rule on the server to block any inbound and outbound TCP and UDP traffic to/from remote IP addresses that Eset is detecting as botnet connections. This will identify if the traffic is originating from the server or your network; i.e. outbound traffic, or is originating externally from your network; i.e. inbound traffic.

If the blocked traffic is outbound, this would mean the server or a network device is most likely infected with some type of malware that is attempting to connect to its botnet C&C server. 

If the blocked traffic is inbound, it again would indicate a vulnerability in regards to port 443 at the border edge of the gateway. If the gateway has a firewall and it is stateful, it should be auto dropping any unsolicited TCP port 443 inbound traffic; i.e. not in response to a previous outbound port 443 request, at the border edge of the gateway.

Finally, the Eset firewall is stateful and will warn about unstateful inbound TCP traffic via its IDS protection. Since this appears not to be happening, it is a further indication that this botnet traffic being detected is outbound traffic.

Share this post


Link to post
Share on other sites

Also as noted in this Eset article: https://www.virusradar.com/en/glossary/botnet , Eset is analyzing outbound network traffic for connections to known botnet C&C servers. So you need to concentrate on what device/s and processes running on the source devices that is generating the outbound traffic.

Another possibility since you originally posted that this Eset alert is from inbound connections is your gateway has been hacked by the botnet perpetrator. The gateway is sending the outbound traffic, receiving response inbound traffic from the botnet C&C, and attempted to forward that inbound traffic to your internal network.

Share this post


Link to post
Share on other sites

We are getting lots of these alerts for various NAT rules we have. RD Web (443 internally) and SFTP (22 internally) - we use obscure ports externally but these still get hit.

It's not entirely clear what Botnet.C&C.Generic is? Is this a known list of IP's that ESET blacklists or known list of specific botnets bundled into the "Generic" tag/list? Can we have access to this list for blocking?

It would be good to have more information here so we can make an informed decision on what do at our perimeter firewall? We can't close these ports externally but can secure ports based on thing such as location which we've been doing.

Can anyone at ESET support give us a bit of technical explanation here? Given it's the number 1 top worlwide threat on virus radar I think this would help us all a bit.

 

Share this post


Link to post
Share on other sites

Botnet.CnC.Generic is detection of brute-force attacks, typically RDP but it can also be SQL or SMB attacks.

While the detection is not very generic now, it will be soon so there won't be any particular IP addresses that it pertains to.

Share this post


Link to post
Share on other sites
4 hours ago, speakerbox said:

and SFTP (22 internally) - we use obscure ports externally but these still get hit.

Quote

Attacks on SSH port 22 were the third most targeted, which represent brute force password attempts to gain remote access to a machine. However, researchers noted attacks also use IoT malware on this port.

According to the report, the prevalence of attacks is most likely due to the continuing spread of IoT devices, the prevalence of Eternal Blue, and an increase in DDoS attacks. And 99.9 percent of traffic to the honeypot was automated traffic from bots, malware, and other tools.

https://healthitsecurity.com/news/smb-iot-attacks-rapidly-increasing-while-mirai-malware-dominates

Share this post


Link to post
Share on other sites

I'm getting a lot of these blocked as well. We moved an RDP listening port to a non-standard port on a specific device that was routed to 1 Windows 10 PC.   

ESET picked up the port being probed and allowed that until December 11 when it then blocked access to communication to svchost.exe from specific IP addresses under Rule/Worm name Botnet.CnC.Generic.  All of these were inbound, there was no outbound traffic.

The blocking started at the exact same time the Detection Engine was updated to version 20494. Instantly we started getting the blocking. 

The most common source was 193.188.22.80, which was registered to an address in Los Angeles,CA  to a Russian name and resolves to a Russian address.

We blocked that port's inbound access at the firewall and that shut it all down. 

My read on this is that the bots first find an open port, and then attempt to identify what protocol it is looking for. They then try a brute force attack , thousands or millions of times against that port.  We were getting up to 6 hits a second against this port when we shut it off.

I suspect that the version 20494 had a list of botnet sources that was implemented for blocking, or was able to read their signature somehow.  I'm very appreciative that this all happened automatically, but I would have liked the intervention to be more obvious and send me alerts rather than discovering in the logs on my own.

Share this post


Link to post
Share on other sites
10 hours ago, Listo said:

I'm very appreciative that this all happened automatically, but I would have liked the intervention to be more obvious and send me alerts rather than discovering in the logs on my own.

Based on this: https://help.eset.com/eea/7/en-US/idh_config_alert.html , an alert in EEA/EES ver. 7.2 should have been generated unless:

Quote

Disabling Display interactive alerts will hide all alert windows and in-browser dialogs. A pre-defined default action will be automatically selected (for example, "potential phishing website" will be blocked).

 

Share this post


Link to post
Share on other sites
7 hours ago, itman said:

Based on this: https://help.eset.com/eea/7/en-US/idh_config_alert.html , an alert in EEA/EES ver. 7.2 should have been generated unless:

 

Actually my configuration is exactly that, other than I'm using a business version Endpoint Security rather than Endpoint Antivirus.

It doesn't alert on blocked connections for me, but they are in the logs. 

I have email alerts enabled too, so for viruses I do get both an alert and an email.

 

Share this post


Link to post
Share on other sites

Just saw this recent posting over at reddit:

Quote

Botnet.CnC.Generic

Probably a bit random but chance someone might know. Botnet.CnC.Generic is an ESET antivirus definition of a botnet that's on rise just now.

Anywhere we have a NAT mapping on a Fortinet (like https etc.) we're getting alerts from ESET that computers on that Botnet are hitting the internal systems. No big issue and systems are patched and ESET also blocks.

I'm wondering why the Fortinet isn't doing more there though and that we've misconfigured. I'd prefer Fortinet blocked it before it got to ESET. I presume ESET has a database of public botnet IPs and uses that. Expected fortinet IPS would do something similar and be better than ESET?

 

https://www.reddit.com/r/fortinet/comments/ejdj12/botnetcncgeneric/

 

Share this post


Link to post
Share on other sites
2 hours ago, itman said:

I think we are discussing slightly different products, since I'm on Endpoint Security, not Endpoint Antivirus. Those menus aren't quite the same for me. 

I did find this, specifically stating they don't give alerts.

 

image.thumb.png.777e424283ed8031b2fd6e1f4b2d888c.png

Share this post


Link to post
Share on other sites
5 hours ago, Listo said:

I think we are discussing slightly different products, since I'm on Endpoint Security, not Endpoint Antivirus. Those menus aren't quite the same for me.

Do you have the latest version of Endpoint Security 7.2 installed?

Share this post


Link to post
Share on other sites
11 hours ago, Listo said:

I did find this, specifically stating they don't give alerts.

Below is a screen shot from EIS showing default Intrusion Detection settings. As far as I am aware of, its IDS options are the same as for EES. Make sure the option for "Display notification after attack detection" is enabled:

Eset_IDS.thumb.png.a5b927bd1f3bee2555e941d0f7ed20c8.png

You also might want to enable "Display notifications also for incoming attacks against security holes" although Eset online help is ambiguous as to what these actually are.

Share this post


Link to post
Share on other sites
1 hour ago, itman said:

Below is a screen shot from EIS showing default Intrusion Detection settings. As far as I am aware of, its IDS options are the same as for EES. Make sure the option for "Display notification after attack detection" is enabled:

Eset_IDS.thumb.png.a5b927bd1f3bee2555e941d0f7ed20c8.png

You also might want to enable "Display notifications also for incoming attacks against security holes" although Eset online help is ambiguous as to what these actually are.

I wonder why this is not enabled by default (to show incoming attacks against security vulnerabilities)

Share this post


Link to post
Share on other sites

I will also add that the setting determining whether the Eset firewall is operating in statefull mode is controlled by the following Packet Inspection setting. Make sure it's always enabled:

Eset_Stateful.thumb.png.883840b267f51944123ecb37b4a45898.png

Share this post


Link to post
Share on other sites
5 hours ago, Rami said:

I wonder why this is not enabled by default (to show incoming attacks against security vulnerabilities)

My best guess is the scenarios described in this thread. The device being attacked would end up in a perpetual notification status.

Share this post


Link to post
Share on other sites

I have been seeing a similar issue but with a 3rd party application Techspeak 3 server, it 1st occurred on the file default  transfare port, so i changed that port problem went away until today, eset scans detect nothing  on my pc ??????

Share this post


Link to post
Share on other sites
2 hours ago, tommy456 said:

I have been seeing a similar issue but with a 3rd party application Techspeak 3 server, it 1st occurred on the file default  transfare port, so i changed that port problem went away until today, eset scans detect nothing  on my pc ??????

To start off, please provide logs collected with ESET Log Collector for perusal.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...