kamiran.asia
-
Posts
306 -
Joined
-
Last visited
-
Days Won
1
Posts posted by kamiran.asia
-
-
3 minutes ago, Marcos said:
Just to make sure, did the performance issue occur even before you created Windows firewall rules to block the malicious communication?
Nothing changed , We still saw these attacks while no ports was open and still performance issue occur.
seems that ESET Firewall driver work before windows firewall and still analyze inbound packets !
-
8 minutes ago, Nightowl said:
@kamiran.asia, Check in your Firewall rules if you have this enabled
File and Printer Sharing (SMB-In)- TCP 445
And does this server have HTTP opened? And they also try to come by HTTPS.
The exploitation attempts that dear @Marcos mentioned was occurred before we configure Windows Firewall to block all inbound TCP and UDP. So we have no open port right now. Just a limited secure RDP on special IPs. ekrn still use high cpu in this situation.
18 minutes ago, Marcos said:The case has been reported to developers and is pending for analysis.
Yes we think that s.th go wrong and IDS must not involved like this in such attacks. We temporary Disable IDS so Server work probably and waiting for analysis report and any updates. while there is no open inbound port , there is no worries to temporary disable IDs.
-
Dear friends.
Thank you all for you useful information. 🤩
Our customer just rent a vps in OVH ( Exactly a Cloud server at a VPS ) , he have no access to virtualization firewall or ... , Their support said " These udp attacks are general and normal at many servers !! " They advice him to block such these traffics by Windows Firewall. ( As we do )
right now we are not sure that IDS high usage of cpu is related to these udp packets.
Right now we block all inbound UDP and TCP port by windows firewall and we must disable IDS and botnet Permanently ( Because they can not work with server due to cpu usage over 70%)
We are waiting for dear @Marcos that if he find any thing in advanced OS logging that can help : https://we.tl/t-MRdRdaMqvF
-
4 minutes ago, itman said:
What is being blocked is incoming SSDP; i.e. uPnP traffic. Only local subnet inbound traffic to port 1900 is allowed by both the Win and Eset firewall.
Appears to me your gateway/router has been hacked. It's firewall should have never been allowing this outbound traffic from it. It should only be forwarding local subnet traffic.
Hi dear @itman This Server is our customer's VPS in OVH DataCenter. and we have not any access to gateway/router.
We know that s.th is wrong here that ESET IDS is involved. We are working on it and waiting for @Marcos to check the ESET Log Collector.
-
47 minutes ago, Marcos said:
Please enable advanced OS logging in the advanced setup under Tools -> Diagnostics when you notice the cpu hog. After 2-3 minutes disable logging. Make sure that there are no big dumps in C:\ProgramData\ESET\ESET Security\Diagnostics (we don't need them) and collect fresh logs with ESET Log Collector.
As to whether Windows firewall evaluates rules prior to after ESET, we don't know. It should be that ESET scans the communication first.
Here is your requested log dear marcos : https://we.tl/t-MRdRdaMqvF
-
Windows Firewall Dropped Log is attached. also Uploaded to https://we.tl/t-rU7u763VGL
2021-07-14 10:19:31 DROP UDP 51.255.115.138 239.255.255.250 57942 1900 201 - - - - - - - RECEIVE 2021-07-14 10:19:31 DROP UDP 152.228.149.234 239.255.255.250 50664 1900 202 - - - - - - - RECEIVE 2021-07-14 10:19:32 DROP UDP 51.255.115.138 239.255.255.250 57942 1900 201 - - - - - - - RECEIVE 2021-07-14 10:19:32 DROP UDP 152.228.149.234 239.255.255.250 50664 1900 202 - - - - - - - RECEIVE 2021-07-14 10:19:33 DROP UDP 51.255.115.138 239.255.255.250 57942 1900 201 - - - - - - - RECEIVE 2021-07-14 10:19:33 DROP UDP 152.228.149.234 239.255.255.250 50664 1900 202 - - - - - - - RECEIVE 2021-07-14 10:19:34 DROP UDP 51.255.115.138 239.255.255.250 57942 1900 201 - - - - - - - RECEIVE 2021-07-14 10:19:55 DROP UDP 51.255.115.140 239.255.255.250 51999 1900 201 - - - - - - - RECEIVE 2021-07-14 10:19:56 DROP UDP 51.255.115.140 239.255.255.250 51999 1900 201 - - - - - - - RECEIVE 2021-07-14 10:19:57 DROP UDP 51.255.115.140 239.255.255.250 51999 1900 201 - - - - - - - RECEIVE 2021-07-14 10:19:58 DROP UDP 51.255.115.140 239.255.255.250 51999 1900 201 - - - - - - - RECEIVE 2021-07-14 10:20:07 DROP UDP 54.38.229.21 239.255.255.250 55629 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:08 DROP UDP 54.38.229.21 239.255.255.250 55629 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:09 DROP UDP 54.38.229.21 239.255.255.250 55629 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:10 DROP UDP 54.38.229.21 239.255.255.250 55629 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:12 DROP UDP 51.255.115.139 239.255.255.250 60076 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:13 DROP UDP 51.255.115.139 239.255.255.250 60076 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:14 DROP UDP 51.255.115.139 239.255.255.250 60076 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:14 DROP UDP 152.228.149.239 239.255.255.250 52484 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:15 DROP UDP 51.255.115.139 239.255.255.250 60076 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:15 DROP UDP 152.228.149.239 239.255.255.250 52484 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:16 DROP UDP 152.228.149.239 239.255.255.250 52484 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:17 DROP UDP 152.228.149.239 239.255.255.250 52484 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:25 DROP UDP 152.228.149.237 152.228.149.255 138 138 229 - - - - - - - RECEIVE 2021-07-14 10:20:40 DROP UDP 152.228.149.244 239.255.255.250 60322 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:41 DROP UDP 152.228.149.244 239.255.255.250 60322 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:42 DROP UDP 152.228.149.244 239.255.255.250 60322 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:43 DROP UDP 152.228.149.244 239.255.255.250 60322 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:44 DROP UDP 152.228.149.252 239.255.255.250 61878 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:45 DROP UDP 152.228.149.252 239.255.255.250 61878 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:46 DROP UDP 51.255.115.141 239.255.255.250 64900 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:46 DROP UDP 152.228.149.242 239.255.255.250 55633 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:46 DROP UDP 152.228.149.252 239.255.255.250 61878 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:47 DROP UDP 51.255.115.141 239.255.255.250 64900 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:47 DROP UDP 152.228.149.242 239.255.255.250 55633 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:47 DROP UDP 152.228.149.252 239.255.255.250 61878 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:48 DROP UDP 51.255.115.141 239.255.255.250 64900 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:48 DROP UDP 152.228.149.242 239.255.255.250 55633 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:49 DROP UDP 51.255.115.141 239.255.255.250 64900 1900 202 - - - - - - - RECEIVE 2021-07-14 10:20:49 DROP UDP 152.228.149.242 239.255.255.250 55633 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:05 DROP UDP 152.228.149.250 239.255.255.250 53798 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:06 DROP UDP 152.228.149.250 239.255.255.250 53798 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:07 DROP UDP 152.228.149.250 239.255.255.250 53798 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:08 DROP UDP 152.228.149.250 239.255.255.250 53798 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:24 DROP UDP 54.38.229.19 239.255.255.250 60066 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:24 DROP TCP 134.209.122.227 152.228.149.230 52399 80 40 S 4236672370 0 65535 - - - RECEIVE 2021-07-14 10:21:25 DROP UDP 54.38.229.19 239.255.255.250 60066 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:26 DROP UDP 54.38.229.19 239.255.255.250 60066 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:27 DROP UDP 54.38.229.19 239.255.255.250 60066 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:27 DROP UDP 152.228.149.226 239.255.255.250 52031 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:27 DROP UDP 152.228.149.231 239.255.255.250 50707 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:28 DROP UDP 152.228.149.226 239.255.255.250 52031 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:28 DROP UDP 152.228.149.231 239.255.255.250 50707 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:29 DROP UDP 152.228.149.226 239.255.255.250 52031 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:29 DROP UDP 152.228.149.231 239.255.255.250 50707 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:30 DROP UDP 152.228.149.234 239.255.255.250 50665 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:30 DROP UDP 152.228.149.226 239.255.255.250 52031 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:30 DROP UDP 152.228.149.231 239.255.255.250 50707 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:31 DROP UDP 51.255.115.138 239.255.255.250 57943 1900 201 - - - - - - - RECEIVE 2021-07-14 10:21:31 DROP UDP 152.228.149.234 239.255.255.250 50665 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:32 DROP UDP 51.255.115.138 239.255.255.250 57943 1900 201 - - - - - - - RECEIVE 2021-07-14 10:21:32 DROP UDP 152.228.149.234 239.255.255.250 50665 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:33 DROP UDP 51.255.115.138 239.255.255.250 57943 1900 201 - - - - - - - RECEIVE 2021-07-14 10:21:33 DROP UDP 152.228.149.234 239.255.255.250 50665 1900 202 - - - - - - - RECEIVE 2021-07-14 10:21:34 DROP UDP 51.255.115.138 239.255.255.250 57943 1900 201 - - - - - - - RECEIVE 2021-07-14 10:21:55 DROP UDP 51.255.115.140 239.255.255.250 53107 1900 201 - - - - - - - RECEIVE 2021-07-14 10:21:56 DROP UDP 51.255.115.140 239.255.255.250 53107 1900 201 - - - - - - - RECEIVE 2021-07-14 10:21:57 DROP UDP 51.255.115.140 239.255.255.250 53107 1900 201 - - - - - - - RECEIVE 2021-07-14 10:21:58 DROP UDP 51.255.115.140 239.255.255.250 53107 1900 201 - - - - - - - RECEIVE 2021-07-14 10:22:07 DROP UDP 54.38.229.21 239.255.255.250 55630 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:08 DROP UDP 54.38.229.21 239.255.255.250 55630 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:09 DROP UDP 54.38.229.21 239.255.255.250 55630 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:10 DROP UDP 54.38.229.21 239.255.255.250 55630 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:12 DROP UDP 51.255.115.139 239.255.255.250 56678 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:13 DROP UDP 51.255.115.139 239.255.255.250 56678 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:14 DROP UDP 51.255.115.139 239.255.255.250 56678 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:14 DROP UDP 152.228.149.239 239.255.255.250 52485 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:15 DROP UDP 51.255.115.139 239.255.255.250 56678 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:15 DROP UDP 152.228.149.239 239.255.255.250 52485 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:16 DROP UDP 152.228.149.239 239.255.255.250 52485 1900 202 - - - - - - - RECEIVE 2021-07-14 10:22:17 DROP UDP 152.228.149.239 239.255.255.250 52485 1900 202 - - - - - - - RECEIVEFind many UDP Dropped logs. All from OVH SAS , As this server is a vps in OVH.
But these udp ports are blocked. We can not find why ESET IDS is involved with CPU usage of 70% yet.
-
3 minutes ago, Nightowl said:
Put your Windows Firewall to log dropped attempts and see what is being dropped since you denied all INCOMING it must be logged there
We are confused that If ports are dropped , Why ESET IDS will involved ?! ESET Network driver are working before Windows firewall ?
We will check Windows firewall dropped log.
-
1 minute ago, Nightowl said:
You don't have a port when you click Details in Network Protection Troubleshoot?
No , As you can see in screenshots Destination Port and any other info is N/A !
All inbount TCP and UDP are block by windows firewall but still ESET IDS is involved with attacks.
-
48 minutes ago, Marcos said:
Looks like the server is being heavily attacked. Please provide logs collected with ESET Log Collector.
Thank you dear @Marcos for rapid reply as always, The Man Number1 of ESET Forum Administrators 😍
-
Hi dear ESET Admins,
In These 2-3 days we have a problem in many VPS that FS V7.3 or 8.0 are installed.
Over 70-90 % of Cpu use by Ekrn, When IDS and Botnet Protection is disable there is no problem (Ekrn cpu usage will be less that 1%).
our support team disable all firewall policy , Block All inbound UDP and all TCP inbount in Windows Firewall (and Limit RDP with IP Whiltelist in Windows FireWall).
Still we see many Attacks in IDS log and many Blocked IP !
Ekrn dump and EpfwLog.pcapng are uploaded here : https://we.tl/t-raMXXS0y2n
What is the cause of this attack while all tcp and udp port are closed by Windows firewall !?
-
Dear ESET Admins,
Did you check the problem ?
Our Customers have problem to use v8.1 in offline environment.
-
10 hours ago, itman said:
You can also download the source code for the .dll used in this test, add some additional code
In Our tests ESET will detect attack with any DLL file , Even with an empty file ! it does not depend on detection of Dll file.
10 hours ago, itman said:Also check this out which tests the previous known vulnerabilities: https://github.com/cube0x0/CVE-2021-1675
We will also check that.
-
6 hours ago, itman said:
An RPC exploit which is what this vulnerability is about would be using port 135
Thank u dear ,
Do you have that exploite code to test ?
-
Hi dears.
We test this PrintNightmare-CVE-2021-34527 exploit : https://www.thedutchhacker.com/how-to-exploit-the-printnightmare-cve-2021-34527/ in our test lab at a unpached win2016 and ESET FileSecurity IDS detect it as
7/9/2021 1:52:59 PM;Web threat;Blocked;192.168.235.161:50426;192.168.235.176:445;TCP;SMB/RiskWare.Generik.A;System;0000000000000000000000000000000000000000;
If you disable IDS in this kind of exploit , reverse.dll will be detect as a variant of Win64/Injector.EO trojan by ESET.
If there is any other Exploit , We can test it and publish the result.
-
Dear @Marcos ,
We regenerate the error in our test environment and this is the ESET Log Collector.
We install ESET Protect and EES in windows 10 system for TEST.
Also used offline file in this test is attached.
ESET Log Collector log : https://we.tl/t-k34sC0doYI
-
44 minutes ago, Marcos said:
Please provide also the offline license file. When creating the offline license file, did you enable management by ESET PROTECT? Did you activate Endpoint from ESET PROTECT or locally? I've tested local activation and it worked. Could you test local activation as well?
I think you test it locally but the problem is just activation task from ESET Protect console.
Even All-in-one-Installer will work .
Local Activation will work.
-
11 minutes ago, labynko said:
Hello.
I acknowledge the problem.
Used software versions:
ESET PROTECT 8.1.13.0
ESET Management Agent 8.1.1223.0
ESET Endpoint Security 8.1.2031.0Exactly . But the problem is at ESET Endpoint Security 8.1.2031.0 , Because when we downgrade to 8.0 the problem solved !
@Marcos We will reproduce the problem and send ESET Log Collector.
-
22 hours ago, itman said:
An Eset reinstall fixed the HIPS issue and it's now detecting properly write activity to C:\Windows\System32\spool\drivers\*.
What may have caused this HIPS malfunction was a few days ago, I had an Eset module update hang on me. I cancelled it via Eset GUI option but even then, it "sputtered" a bit. Appears this corrupted the HIPS module in some way.
The real scary part here is Eset gave no indication that the HIPS was not functioning properly. Luckily, I always test my HIPS rules for functionality. Otherwise, I would have never detected this issue.
@kamiran.asia a FYI. Windows periodically updates its fax drivers in C:\Windows\System32\spool\drivers\ directory. So an absolute block on write activity it its sub-directories will cause these updates to fail and possibly other Win Update issues.
@itman Thank you.
But in some old networks we have even 2008R2 and windows 7 without ESU . So Print PrintNightmare patches can not be installed and print spooler can not be disabled !
It seems that the only way to work against PrintNightmare is HIPS Rule in such these old environments.
IT Administrators must disable that HIPS rule via console or locally to add a printer or update a driver.
Also McAfee publish an Expert Rule that is similar to our HIPS solution :
https://kc.mcafee.com/corporate/index?page=content&id=KB94659
As you said use this expert rule may cause issues for McAfee users.
-
Hi Dears.
Any Idea or Any Help ?
-
We test this solution and we think it is useful for CVE-2021-34527.
It work and block : C:\Windows\System32\spool\drivers\*
-
Hi Dears.
as you know about kaseya ransomware Attack. it is necessary that ESET work on a antiCryptor Module .
As We test REvil sample in a Not Updated EES , Ransomware Shied do nothing while LiveGride was Enable !
If you test it in a not updated product you can see that Ransomware Shied can not detect the encryption possess.
So before this detection Win32/Filecoder.Sodinokibi.N trojan on July 2nd at 3:22 PM (EDT; UTC-04:00) Agent.exe was able to crypt all infected system files.
We think that Ransomware Shied must be more powerful !
-
Hi Dears ESET Admins.
We find a problem in ESET Endpoint Security 8.1.2031.0 - 64Bit
The Security Product in a isolate network without internet will not Activate via ESET Protect Console with Offline License !
Locally Activation with offline license file will work but Activation task with Offline License file will failed with error " Task failed in the security product"
Downgrading to EES 8.0 will resolve the issue.
It seems that EES 8.1.2031.0 can not activate with offline activation task.
We test it in over 3 network and over 3 different console but problem is same !
-
Hi Dears.
We find a problem in ESET Protect WebConsole at Installer --> GPO or SCCM Script
( Windows Server 2016 - ESET Protect 8.1 Latest Version , Browser : Chrome v 91)
When a group is selected it does not show selected group and then Server host name can not be edited any more. Also selected Agent Policy not show . But all these setting will be applied in generated INI. it seems a Graphical problem.
If you set Hostname first it will be possible to choose static group !
-
Bad news ! Nightmare now has a new CVE and officially not patched !
https://www.zdnet.com/article/microsoft-adds-second-cve-for-printnightmare-remote-code-execution/
IDS use over 70% of CPU & too many attacks detected
in ESET Products for Windows Servers
Posted
Yes ,we agree with you. in many other project and servers when we block incoming port ( i.e 445 ) ESET did not report any attack from those blocked ports. But in this case we are confused ! how these traffic are received by ESET firewall driver. or may be these attacks are not TCP / UDP that cause IDS performance issue ! ( because we just Block TCP / UDP inbound protocol in WF) but while ESET IDS did not report any target port we can not realize how these black list ip are accessing the server.