JamesR

As you did not share any data, I will be be sharing a very generic how to that may or may not work for you. If it doesn't, I will need a bit more info on what you are seeing in the details of the detection. Main assumption is that you have some sort of SSH Server process, on Linux/macOS, which is getting detections on one of our SSH Rules. You will need to use an Advanced Exclusion. I would recommend to use a "Process" and "Operations" section to state, "When a specific IP is seen starting an inbound connection to process named ssh in path /abc/efg/, it is expected and do not trigger detection." Some notes before I show the rule: TcpIpConnect = outbound connection TcpIpAccept = inbound connection Here is how you can exclude multiple IP addresses (ensure you are defining each address as either IPv4 or IPv6): <definition> <process> <!-- Define attributes about your process of interest here --> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="sshServer"/> <condition component="FileItem" property="Path" condition="starts" value="/your/path/here/"/> </operator> </process> <operations> <!-- Inbound IP Addresses excluded from detection --> <operation type="TcpIpAccept"> <operator type="or"> <condition component="Network" property="IpAddressV4" condition="is" value="10.0.0.138" /> <condition component="Network" property="IpAddressV6" condition="is" value="fe80::1ff:fe23:4567:890a" /> </operator> </operation> </operations> </definition> If you are looking to only exclude a single IP, the "operator type" will change to the following: <definition> <process> <!-- Define attributes about your process of interest here --> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="sshServer"/> <condition component="FileItem" property="Path" condition="starts" value="/your/path/here/"/> </operator> </process> <operations> <!-- Single inbound IP Address excluded from detection --> <operation type="TcpIpAccept"> <operator type="and"> <condition component="Network" property="IpAddressV4" condition="is" value="10.0.0.138" /> </operator> </operation> </operations> </definition> Lastly, lets say you want to exclude both inbound and outbound connections, you can then use something similar to the following: <definition> <process> <!-- Define attributes about your process of interest here --> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="sshServer"/> <condition component="FileItem" property="Path" condition="starts" value="/your/path/here/"/> </operator> </process> <operations> <!-- Inbound IP Addresses excluded from detection --> <operation type="TcpIpAccept"> <operator type="or"> <condition component="Network" property="IpAddressV4" condition="is" value="10.0.0.138" /> <condition component="Network" property="IpAddressV6" condition="is" value="fe80::1ff:fe23:4567:890a" /> </operator> </operation> <!-- Outbound IP Addresses excluded from detection --> <operation type="TcpIpConnect"> <operator type="or"> <condition component="Network" property="IpAddressV4" condition="is" value="10.0.0.138" /> <condition component="Network" property="IpAddressV6" condition="is" value="fe80::1ff:fe23:4567:890a" /> </operator> </operation> </operations> </definition>

What you are trying to accomplish, will require an Advanced Exclusion that makes use of an <operations> section. The <operations> section, can be a bit tricky to become used to. Its formatting is as follows: <operations> <!-- This "operations" tag is plural --> <operation type="WriteFile"> <!-- This "operation" tag is singular, and defines the type of operation you want to exclude --> <operator type="and"> <!-- Define any needed operator of and/or/not --> <condition component="FileItem" property="FullPath" condition="is" value="%Path%\Of\Interest\to\fileName.xyz"/> <!-- Define any/all conditions of ineterest to describe the actions being taken by a process. --> </operator> </operation> </operations> Your detection is being caused by a "FileTruncated" event. This is part of the "WriteFile" operation. Here is my recommended style of exclusion is to specify the specific Process, and the specific "WriteFile" operation for a specific location and file extension (modify any file paths needed): <definition> <!-- First we define the process we want to not trigger the detection. This will restrict the exclusion to specific executables causing the incorrect detections --> <process> <operator type="AND"> <!-- SignatureType of 90 = Trusted --> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90"/> <!-- Following will allow for both possible locations of outlook.exe --> <operator type="or"> <condition component="FileItem" property="FullPath" condition="is" value="%PROGRAMFILES(X86)%\microsoft office\root\office16\outlook.exe"/> <condition component="FileItem" property="FullPath" condition="is" value="%PROGRAMFILES%\microsoft office\root\office16\outlook.exe"/> </operator> <!-- Signer Name must be "Microsoft Coroporation --> <condition component="Module" property="SignerName" condition="is" value="Microsoft Corporation"/> </operator> </process> <!-- Next we define which type of operation or target we want to allow the above process to do, without triggering a detection --> <!-- Logic here will state that we do not want detections on .com files created inside of the "...\inetcach\content.mso\" directory --> <operations> <operation type="WriteFile"> <operator type="and"> <!-- Full File Path must start with expected location --> <condition component="FileItem" property="FullPath" condition="starts" value="%LOCALAPPDATA%\microsoft\windows\inetcache\content.mso\"/> <!-- Full File Path must end with .com to ensure we are only excluding the .com files. --> <condition component="FileItem" property="FullPath" condition="ends" value=".com"/> </operator> </operation> </operations> </definition> Please note that I am using the property "FullPath" for my "<condition..." statements. FullPath is a combination of "FileName" and "Path" properties. I like to use this so that I can easily use "Starts" or "Ends" condition properties as needed. FileName = File name with extension like, "HowdyThere.exe" Path = file path ending with a "\" like, "C:\some\path\of\interest\" FullPath = both Path and FileName in one complete string like, "C:\some\path\of\interest\HowdyThere.exe"

I made a tiny adjustment to your exclusion, can you try the below to see if it works? In short, I changed "FileItem" to "ClientFileItem". <definition> <operations> <operation type="WmiQuery"> <operator type="and"> <condition component="WmiQueryInfo" property="Query" condition="contains" value="select displayname,instanceguid,productstate,timestamp from antivirusproduct" /> <condition component="ClientFileItem" property="FileName" condition="is" value="pangphip.exe" /> </operator> </operation> </operations> </definition>

Its likely that the external URL for OAB has a WebShell one-liner in its URL. To check for and to remediate this, please do the following. JS/Exploit.CVE-2021-26855.Webshell.H is an IOC detection which simply means your Exchange server was exploited in the past by this CVE. Ensure you your Exchange server is fully patched, and then perform the following to remove the remnants of attack. Check the following on the Exchange Server: 1. Use a web browser to access: https://127.0.0.1/ecp a. Login with an admin that has enough rights (might require exchange admin) 2. Click on "Servers" on the left 3. Click on "Virtual Directories" tab thing in top middle area 4. double click on "OAB Default Website" (OAB = Offline Address Book) 5. Check what is in the 2 URL fields a. Internal URL b. External URL 6. Copy and paste any suspicious URL fields into Notepad (with word wrap enabled) and then save a screenshot and discard the Notepad a. Saving the raw text will cause a detection by ESET. 7. Save your changes and then move on to either rebooting the exchange server or restarting IIS. a. Without restarting IIS, then the IIS server will continue to host the AutoDiscovery settings which cause detections on endpoints with outlook. Here is what this looks like on my non-compromised test environment: Restarting IIS (or just reboot the server) Open "Internet Information Services (IIS) Manager" (Windows + R > inetmgr.exe) Click on your server name in the list (mine test environment showed: SVRSANDEXCH (DEMO\Administrator)) On the far right under actions, click "Restart" (or you can right click on the server name and choose "stop" then "start") This made outlook on my test workstation go offline for about 30 seconds (likely longer in a production environment) and I no longer got any of the cached OAB URLs which caused detections. After this, all endpoints may get one, or more, final detection as they clean up any remaining copies of AutoD/AutoDisovery XML files, but the total count of detections of webshells per day, should go decrease until you no longer have any of these detections.

I would not recommend deleting powershell and replacing it. Powershell is not infected, it is just being misused. As it has been about a week, can you generate a new ESET Log Collector to provide here? When running ESET Log Collector, please ensure to select the profile "All" before clicking the "Collect" button. This will ensure we get as many logs as possible for this:

I can send you a private DM. Then only I would see any info you share. Would this be OK? You can blur out or omit the computer name section, but there is always a chance of other username/computer name data in the box containing "Event", "Command Line", "Username" having some info you may want to omit as well. The piece of the puzzle that is most important for exclusion problems, is typically the "Event" data. But it can also be other things like "Command Line" or "parent/ancestor process".

@avielc, While supplying these screenshots, can you ensure you capture all 4 of the information panes on the left like the example below? This will ensure we can see the process tree and the event data which may have lead to the detection. Also, it will be important to share a copy of the exclusion which is not working as expected (exporting the exclusion as XML will be best). Also, please double check the exclusion is enabled. I'm certain it is, but its best to double check and rule that out. There is a chance we might need an export of the Raw Events, but that is only if the screenshots, with all 4 panes of info, is not enough to see what is happening.

I assisted Shogun1 with some more cleanup. There were 2 other scheduled tasks which used the same lolbin trick. Not uncommon for these powershell scheduled tasks to leverage multiple scheduled tasks to increase their persistence. Samples of everything have been gathered and submitted.

Could you clarify if you are using MS SQL or MySQL? Also, is your SQL DB using a second drive? It could be the SQL server is using a temp folder on the primary drive where the OS is installed. The nightly purges will create a lot of temporary files, so its important to ensure that the your SQL server is using a Temp directory, on a drive with enough space.

Artemis, There is a difference between "Events" and "Detections" which you might be confusing. Events are the low level data that is logged by EEI (file and registry writing, Tcp connections, WMI events, etc). This data can take up the bulk of disk space for an EEI server. Detections are made from rules which parse the logged events. If EEI was not optimized after install, it can lead to a large flood of detections which can slow down the EEI server if never resolved. Your description of the the issue leads me to believe you EEI environment has not been optimized to create a baseline on your environment and the number of detections is overwhelming the server. There are a couple things you should backup and try before purging the entire Database. Items to backup Exclusions Log into the EEI Web console and navigate to: Admin > Exclusions Remove any filtering from your view. Checkmark all exclusions, and click "Export" and save the exclusions in a safe location. You can re-import these after the database is purged and recreated Event Filters Log into the EEI Web Console and navigate to: Admin > Event Filters Remove any filtering of your view Checkmark all filters, and click "Export" and save the exclusions in a safe location. You can re-import these after the database is purged and recreated One thing to try before purging the data Change the "Database Retention" and the type of data retained by "Data Collection" Log into the EEI Web console and navigate to: Admin > Server Settings Change how long to retain both of the following settings: Store low-level data for: 7 days (this is very standard to only retain the low level event data for 7 days) Store detections for: 1 week (we are only temporarily changing to this and after the EEI console is usable again, change it back to your desired retention) The next time EEI performs its nightly tasks of purging data, it will start purging the excess data. Please be aware that it is possible that it could take several days to fully purge all the excess data. Other things which could cause your same issue: If EEI's SQL DB is installed to the same drive as the OS, it can lead to slow downs. The SQL DB should be installed to a secondary drive. If the SQL DB is using the OS's Temp folder, it can lead to failed nightly purges due to not enough free disk space. You will want to edit the my.ini and set the tmpdir to point to an existing folder on a secondary drive Edit the "...\MySQL\MySQL Server 8.0\my.ini" (preferably with Notepad++ to prevent file encoding from being changed. Locate the [mysqld] and add the following line below it (change the path to be the path to the temp folder you create on the secondary drive): tmpdir = D:\My\Exeternal\temp If the drives your SQL DB is installed on, does not meet the minimum IOPS needed to support the amount of data EEI is actively handling, then you can see performance issues like what you are seeing. Test the IOPS of your SQL server with DiskSpeed (if you need help reading the results, post them in a reply): Change "C:\iotest.dat" to point to the drive hosting SQL diskspd -b32K -d60 -o4 -t8 -h -r -w65 -L -Z1G -c20G C:\iotest.dat > C:\DiskSpeedResults.txt download: https://github.com/microsoft/diskspd/releases/download/v2.1/DiskSpd.ZIP As a last resort, you can use the following steps to purge the entire database. Please only use this as a final resort, as it cannot be undone. These steps are for MySQL. If you are using MS SQL, the steps would be similar Stop the “ESET EI Server” service: net stop EiServerSvc Change Directory to: “%ProgramFiles%\MySQL\MySQL Server 8.0\bin\” Enter the sql shell: mysql -u root -p Run the query: SHOW DATABASES; Drop the EEI DB: DROP DATABASE enterpriseinspectordb; Wait for this to complete. It can take a bit Rerun the query: SHOW DATABASES; When ready, run a repair of the EEI Server

Hello, I am working to get someone to reach out to you ASAP on this open case.

Your symptoms indicate that your MS SQL server may be compromised. Some things you will want to immediately do are: Ensure MS SQL Ports are not exposed to the internet. Typically this will be port 1433 but could be a different port. Audit existing MS SQL user accounts and disable and/or reset the password for all accounts (may need to do this for Windows accounts too as MS SQL can allow the use of Windows Authentication for management) Generate ESET Log Collector logs Check for the following SQL Settings being enabled as they can be abused by attackers: 'xp_cmdshell' - Allows SQL to execute external applications like CMD.exe or Powershell.exe or other 'Ole Automation Procedures' - Allows SQL to execute OLE (similar to MS office macros) and can lead to SQL executing external applications, making network connections, etc... 'show advanced options' - Allows advanced features of SQL to be used (this allows the above features to be used). There are multiple ways MS SQL can be leveraged to execute malicious code. The most popular are: Stored Procedures - Can be scheduled inside of MS SQL to execute at specific intervals Triggers - There are 3 types of triggers DDL (Data Definition Language) - executes code whenever statements like CREATE, ALTER, DROP are used. LOGIN - Executes code whenever a user logs into the MS SQL system. DML - (Data Manipulation Language - executes code whenever statement like INSERT, UPDATE, DELETE are used. .NET - MS SQL does have the ability to execute .NET libraries, but this is much harder and rarer to see. I will send you a direct message with some more specific pointers on identifying if your SQL Server is currently compromised.

Its working fine in my test environment. My environment is running: EEI Server version: 1.6.1755.0 EEI Agent version: 1.6.1738 (I need to update this) ESET Endpoint Security version: 8.1.2031 There is also a chance that the command logged is all that was executed on the endpoint. But its very important to know which version of EEI Server, EEI Agent, and ESET Endpoint product. Screen showing this working in my environment:

I think the time change occurring around when this started is just a coincidence. The error you are getting, indicates that your EEI server's Hard Drive is full (or almost full) or that it has run out of RAM. Please check how much free drive space you have on all drives for the EEI server. Even if you installed the SQL database on a second drive, if the main System Drive (C:\) is full, this could lead to SQL not being able to write to C:\Windows\Temp.

I agree with Marcos, this looks like a WMI persistent threat. Manually telling ESET to update its detection engine, should correct the issue of the threat continually being detected. Although, there is a good chance you may already have the update (ESET checks for these updates once per hour). If this does not fix the issue, definitely generate an Autoruns log. Lastly, its not uncommon for Servers to have been infected due to unexpected ports being exposed to the internet. I highly recommend you audit your public IP Addresses with some simple nmap scans to verify what ports are exposed to the internet. nmap -sV -Pn -F %PublicIPAddress%

Just so you are aware, Emotet uses an email phishing technique where it uses legitimate stolen emails and then spoofs the sender to make it look like a continued email communication. It sounds like these trojan downloaders are appearing via that tactic. Do not exclude them or you risk getting a very dangerous worm like Emotet on your network. "One of Emotet's most devious methods of self-propagation centers around its use of socially engineered spam emails. Emotet's reuse of stolen email content is extremely effective. Once they have swiped a victim's email, Emotet constructs new attack messages in reply to some of that victim's unread email messages, quoting the bodies of real messages in the threads." - https://blog.talosintelligence.com/2019/09/emotet-is-back-after-summer-break.html While the above is from 2019, Emotet has recently resurfaced. And there is always the chance some other attacker is imitating their tactics. Definitely focus on examining the email headers to verify the source IP addresses of the Emails. Its likely you are simply the target of a phishing attack.

It sounds like you have purchased 2 internet lines. One where you have a WIFI Router, and one where you are directly connected to the internet. You should put a router between your computer and the internet. You can easily purchase a router that uses a physical network cable instead of using wifi. Your Wifi router may even have extra Ethernet ports as well. But the key thing is, a router is what hides your computer from others being able to directly see and attack your computer. In short, you need some form of physical hardware that will assign your computer a private IP address, thus stopping the attacks. I would recommend a router that supports an Ethernet (hardwired) connection instead of Wifi. As you will need hardware to help protect your computer, there is not much else we can do on the forums. I highly recommended that you may want to talk with your ISP or a local computer technician to assist in configuring a router that will support a wired connection.

The ESET Log Collector log you supplied shows you have a public IP address directly on your computer. This means you are not behind a router. This is very insecure and you will continue to see these attacks until you place your computer behind a router. If you contact your Internet Service Provider (ISP), they may refer to a router as a gateway, residential gateway, 2 in 1 modem, etc... If my talk of Router/Gateway and Public IP address is a new concept for you, I recommend working with your ISP or a local computer technician who can assist in setting up a router to hide your computer from the internet. Again, I can not emphasize this enough, it is very dangerous to connect a computer directly to the internet where it will be assigned a public IP address. Doing so will lead to non-stop attacks like the ones ESET is showing you.

I do not believe the process path of VNC is a problem, its likely that you utilized a custom path for the install. However, if you have not installed VNC or do not allow it, remove it. The root of the problem is that the computer triggering these detections is exposed to the the internet (directly or via port forwarding). I highly recommend you perform an audit of your public IP addresses. If needed, contact your ISP to get a list of IPs you own/use from them or use google to search for "whats my IP address" on different segments of your network. Next, from a computer which is not on your network, perform an NMAP scan of your public IP addresses to see which ports are open to the internet and to attempt to identify what services are on those ports. Here is one example command you could use (the command is case sensitive): nmap -sV -F -Pn ipaddress Replace "ipaddress" with your public IP Address. Nmap results where ports are seen as "OPEN" or "Filtered" are exposed to the internet. Filtered simply means the port was seen but NMAP could connect to it. This could be due to the IP you are scanning from being blocked. Close any open ports that are not needed to be exposed to the internet. If you have ports you must have open, consider restricting which IP Addresses are allowed to connect to these port (only specific trusted IPs or maybe only IPs in specific regions). Also consider moving ports to only being accessible via a VPN. And consider applying 2FA to any ports which require users to enter their usernames and passwords (ESET does have a 2FA product, but it does not work with VNC by default). If you are wanting more logging on this, you can do 1 of 2 things (or both): Use Wireshark to capture network traffic on the computer in question Use port mirroring if needed Create a policy in ESET Security Management Center to enable Diagnostic logging to create a PCAP of network traffic In ESMC, create a New Policy and select your product (Likely "ESET Endpoint for Windows"). In Settings, navigate to "Tools (on left) > Diagnostics (on left) > expand "Advanced Logging" on right Turn on "Enable Network Protection Advanced Logging" You can turn on all diagnostics if you want, but you wont need every diagnostic log for this Apply the policy to the computer you want the diagnostic logs from. Do not forget to remove the policy from the computer after you have gathered logs while the attack was logged. Otherwise you will fill the Hard Drive rather quickly. The diagnostic logs will be saved locally to the computer that generated them in "C:\ProgramData\ESET\ESET Security\Diagnostics". The pcap files can be opened and examined in Wireshark. Once done gathering logs, ensure you turn diagnostic logging off. Diagnostic logging should only be used when needed, and not left on indefinitely.

One other thing. If you are using Services.msc to start the service, it is not uncommon that the Services.msc GUI can not handle a service that takes a long time to start. Instead, can you do the following after you get an error in Services.msc? Open the properties of your MySQL service and and copy the highlighted "Service Name:" at the top of the properties window. This will likely be mysql57 or mysql8 Open an administrative command prompt and issue the following command: sc query ServiceName Replace ServiceName with the name you identified in step one. Like: sc query mysql57 You should see that the service is still starting. Its not uncommon that the MySQL service will take a long time to start. It is allocating memory and hard drive space. If the service is never starting, check how much free space is on your hard drives. If none of the above works or helps, please ensure you gather the logs Marcos requested before replying.

Hello, please update the detection engine in ESET and the detection method should now be corrected, and the .xml no longer detected.

Which version of ESET is installed? If not on v7.x, you will want to upgrade to v7.x ASAP as it has Network Attack Protection which can block EternalBlue (MS17-010) and help prevent reinfection and assist in identifying IP addresses that are attacking computers on your network. This will also help you verify if this infection is spreading via a network exploit or not. From everything you have posted so far, I see no hard evidence of exploitation via MS17-010. Also, if you can provide logs using ELC (https://support.eset.com/kb3466/?locale=en_US&viewlocale=en_US) this can help identify what is occurring. When running ELC, please set the top drop down list to "Threat Detection".

I have replied directly to dandodds. I have been sick lately, but am feeling much better now.

@itman - Screenshot should be there now. Thanks.

If an issue like this ever returns, I recommend using ESET's Firewall to log or block the activity. To do this, simply make a firewall rule similar to the following: Then you should be able to see the offending exe in the Firewall Log for ESET.