Jump to content

JamesR

ESET Staff
  • Posts

    107
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by JamesR

  1. I would not recommend this. When you create an advanced exclusion, which will use an <operation type="...">, you should have it match the operation type of the triggering event. If you try to use an exclusion with a "DllLoad" operation, and apply the exclusion to a rule which is looking for "CodeInjection", your exclusion will not work as expected. In short, mixing and matching different operations in an exclusion, can break your exclusion. Also, it appears you may be using an older version of our On Premise solution. I would recommend upgrading when you can. The rule tag "[F0413b][C]" is outdated and has been replaced with "[F0413b]".
  2. How often a rule triggers on an event, is dependent on a customer's environment. If a new process starts, and exhibits a behavior which would trigger a rule, that process will trigger the rule. From your screenshot you can see there is a different "Process Name (ID)" for each detection and the same executable each time. This tells me that the executable "7kmdtosm.exe" is being executed multiple times and performing actions which trigger rule "[C0628]". If you have confirmed these detections are not a sign of an attack, you can stop the rule from triggering on this behavior by creating an exclusion. I would recommend using the following Advanced Exclusion as a starting point. The following is an example of how to start building an exclusion for rule [C0628]. Ensure you customize this to match what you are seeing in your own environment. <definition> <process> <operator type="and"> <condition component="FileItem" property="FullPath" condition="is" value="C:\Full\Path\to\7kmdtosm.exe" /> </operator> </process> <!-- Following Operations describe the location and file extension which 7kmdtosm.exe would be writting to. You will need to ensure this matches data you see in your own environment by using the "Trigger Event" column in a detections list, or by opening the details of a detection and looking for the Trigger Event section. --> <operations> <operation type="WriteFile"> <operator type="and"> <condition component="FileItem" property="Path" condition="is" value="%HOME%\Documents" /> <condition component="FileItem" property="Extension" condition="is" value="xyz" /> </operator> </operation> <operation type="RenameFile"> <operator type="and"> <condition component="FileItem" property="Path" condition="is" value="%HOME%\Documents" /> <condition component="FileItem" property="Extension" condition="is" value="xyz" /> </operator> </operation> </operations> </definition>
  3. Your rule is targeting a Process which will have low LiveGrid reputation and popularity. How are you testing the rule? If you are testing by simply downloading an EXE to the system, this will not trigger and would require a more advanced rule (<operations> section).
  4. @Quizzical9796 What you are seeing is not caused by a threat. And it will be best for you to contact your local ESET support to get a ticket and potentially more thorough troubleshooting steps. Some things which can cause what you saw: Older version of ESET Endpoint Protection or Inspect Connector on the endpoint. Ensure you are using the latest versions of Endpoint and Inspect Connector (and latest Inspect Server...if you are using Cloud, you are on latest Inspect Server). Possible solution: Updating to latest versions of endpoint and inspect may resolve this problem Blocking of ESET servers on endpoints If your network is using a UTM/Next Gen Firewall, there is a good chance many of ESETs public servers are being blocked and could lead to ESET not being able to check the validation of a certificate seen on an executable. As the endpoints and the server will both be checking ESET servers for a multitude of things, it could be that your endpoints cant communicate with a handful of ESET servers while your Inspect server has no issues communicating with ESET servers. Possible solution: Ensure you have added ESET public servers to any whitelists/allow lists/exclusions on your UTM/Next Gen Firewall. Full list of servers with Domains/IPs is here: https://support.eset.com/en/kb332-ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall Your local support teams may be able to assist with identifying if there are any communication problems with any ESET servers which could cause what you are seeing.
  5. I was able to get an exclusion working for rule "Powershell.exe creates an external network connection [A0502b]" which has a trigger event of " TcpIpConnect 123.234.231.210:443 (my.example.cloud.azure.com)" (No those are not real IPs or Domains for my test...just examples). Here is the exclusion I made that worked. You should be able to use your "Port" condition as well. Main difference between how I made the "Hostname" condition from yours, is that I used "is", where you used "contains". If it is an exact match, you should use "is". I would also recommend using "Starts" or "Ends" instead of "contains". If this does not help, please let me know what the rule name is so I can try and simulate this in my test environment. Also knowing the EI Server version and EI Connector version, may be important. <definition> <operations> <operation type="TcpIpConnect"> <operator type="and"> <condition component="Network" property="Hostname" condition="is" value="my.example.cloud.azure.com" /> </operator> </operation> </operations> </definition>
  6. Just checked the file internally. We detect it as "Win64/Zemana.A potentially unsafe application".
  7. Appologies for the delay, I didn't see a notification in my inbox (#PEBKAC) Should be something like this: <definition> <operations> <operation type="CreateProcess"> <operator type="AND"> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="&quot;Helpdesk-XYZ&quot; -v &quot;v4.0&quot; -l &quot;webengine4.dll&quot; -a \\.\pipe\*.* -h &quot;C:\inetpub\temp\*.*&quot;"/> </operator> </operation> </operations> </definition> As you can see, all " became &quot; There are many other characters that sometimes need to be converted to their HTML Entity equivalent. The ones I most commonly run into are: & = &amp; " = &quot; < = &lt; > = &gt; If needed, you can use cyberchef's "To HTML Entity" to change a lot of characters into their HTML equivalent ( https://gchq.github.io/CyberChef/#recipe=To_HTML_Entity(false,'Named entities') )
  8. I believe you are building an exclusion for rule "Generic IIS backdoor activity - child process [F0403]" (the ID at the end of the rule name is the most important identifier of the rule. Your exclusion will need to be an Advanced Exclusion and will need to be built to describe the child process to w3wp.exe Here is how to start building the Advanced Exclusion. Begin creating your exclusion as usual. When you get to the criteria you showed in your screenshot, use the "Advanced Editor" button on the top right of the screen. Build XML similar to the following examples and your exclusion should work. Example 1 - excluding single process with single command line <definition> <operations> <operation type="CreateProcess"> <operator type="AND"> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/some command /line parameters"/> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a signature"/> </operator> </operation> </operations> </definition> Example 2 - excluding single process with multiple possible command lines <definition> <operations> <operation type="CreateProcess"> <operator type="AND"> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <operator type="or"> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/some command /line parameters"/> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/other possibleCommand /line parameters /as needed"/> </operator> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a signature"/> </operator> </operation> </operations> </definition> Example 3 - Excluding multiple proccesses <definition> <operations> <operation type="CreateProcess"> <operator type="or"> <operator type="AND"> <!-- First process to describe --> <condition component="FileItem" condition="is" property="FileName" value="NameOfProcessSeen.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\path\to\expected\file\"/> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/some command /line parameters"/> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a signature"/> </operator> <operator type="AND"> <!-- Next process to describe --> <condition component="FileItem" condition="is" property="FileName" value="SecondProcess.exe" /> <condition component="FileItem" property="Path" condition="starts" value="C:\DifferentPath\to\expected\SecondFile\"/> <operator type="or"> <!-- change the condition from "is" to "starts/ends/contains" as needed --> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/more command line items"/> <condition component="ProcessInfo" property="CommandLine" condition="is" value="/other possibleCommand /line parameters /as needed"/> </operator> <condition component="Module" condition="is" property="SignatureType" value="Trusted" /> <condition component="Module" property="SignerName" condition="is" value="Im a DIFFERENT signature"/> </operator> </operator> </operation> </operations> </definition>
  9. @kaboomcanuck Unfortunately your description of the issue does not allow us to identify the source of the TCP Port Scan (Win32/Botnet.generic) detections. This means we cannot yet state if these are being performed by an internal or external IP Address. The best way for us to see what was detected, would be to gather ESET Log Collector logs and provide them to us. At a minimum, please perform step 3 of Marcos' steps. If the source IPs are public IP addresses, and the local ports are not needed to be exposed to the internet, you should close off these ports from the internet (disable port forwarding, place device behind a NAT/Firewall, etc). Any services that can be used to administer a network, should not be exposed to all public IPs on the internet and should be restricted to only IPs which are trusted and allowed to connect. It would be best to block any and all public IPs to administrative services/ports and only allow access to these via private IPs and/or a VPN. If the source IPs are private IPs, you will need to locate the devices with these private IPs and identify if they are devices intended to be performing port scans of the network. If they are not intended to be performing port scans, you will want to ensure endpoint protection is installed and any AV scans have been performed to help rule out malware as the cause. Keep in mind that some software will actively scan a network to identify other devices and that it may not be malware performing the TCP Port scans.
  10. Here is my suggestion with comments to explain what I changed in your exclusion <definition> <!-- <parentprocess> seciton not needed, as it is already built in to rule [F0404] --> <process> <operator type="AND"> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90" /> <operator type="OR"> <!-- restricted CMD to only expected command lines. May want to modify to 'condition="is"' and use full command line. --> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="cmd.exe" /> <condition component="ProcessInfo" property="CommandLine" condition="starts" value="/c &quot;start php.exe eject"/> </operator> <condition component="FileItem" property="FileName" condition="is" value="conhost.exe" /> </operator> <operator type="OR"> <condition component="FileItem" property="Path" condition="starts" value="%SYSTEM%" /> <condition component="FileItem" property="Path" condition="starts" value="%WINDIR%\syswow64\" /> </operator> <condition component="Module" property="SignerName" condition="is" value="Microsoft Windows" /> </operator> </process> <!-- If exclusion is still not working, remove entire operations section and test. --> <operations> <operation type="CreateProcess"> <!-- Was using an "and", but a created process will only ever have a single full path --> <operator type="or"> <condition component="FileItem" property="FullPath" condition="is" value="c:\php\php.exe" /> <condition component="FileItem" property="FullPath" condition="is" value="c:\php\php-cgi.exe" /> </operator> </operation> </operations> </definition>
  11. 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). 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.
  12. "TruncateFile" is an operation which falls under "WriteFile" (yes, annoying that it isn't clearly labeled as such). But you should be able to modify your exclusion as follows to allow it to work. <operations> <operation type="WriteFile"> <operator type="OR"> <condition component="DestFileItem" property="Extension" condition="is" value="dce" /> <condition component="DestFileItem" property="Extension" condition="is" value="blabla" /> </operator> </operation> </operations>
  13. @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.
  14. In ESET Inspect the WMI Persistence events are made up of multiple parts. These parts are "Query", "Invoke", and "Set by user". From your screenshot, I can see that Whenever a query of: "select * from __namespacecreationevent", the action of "" will be invoked. And that this was set by a user with no name. The important part is, the item to be invoked, is nothing. This means nothing happens when the query criteria is seen on the system. In short, this Inspect detection by itself, is not malicious. I would recommend to look for other detections on the same computers which would add to the the story of what happened. If you see nothing on interest, then this is a false positive which should be excluded. If you decide there is no malicious activity which is related to this, and want to exclude this from triggering again, you can use the following as a template for creating the exclusion. <definition> <operations> <operation type="WmiPersistence"> <operator type="and"> <condition component="WmiPersistenceInfo" property="Query" condition="is" value="select * from __namespacecreationevent" /> <condition component="WmiPersistenceInfo" property="Handler" condition="isempty"/> <condition component="WmiPersistenceInfo" property="TriggeringUserName" condition="isempty"/> <!-- if the above does not work, try changing both "isempty" to "isnotset" --> </operator> </operation> </operations> </definition>
  15. As rule F1108a is only looking for execution of netsh processes, there is no need to specify the "FileName" item in your exclusions. I will assume you are seeing something similar or identical to the following (screen is from my test environment): The exclusion I would recommend: <definition> <process> <operator type="AND"> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90" /> <!-- Defining process name is not needed as the rule F1108a will only trigger for netsh. Including it is redundant --> <!--<condition component="FileItem" property="FileName" condition="is" value="netsh.exe" />--> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\" /> <condition component="ProcessInfo" property="CommandLine" condition="is" value="interface tcp show global" /> <condition component="Module" property="SignerName" condition="is" value="Microsoft Windows" /> <condition component="ProcessInfo" property="ProcessOwner" condition="is" value="nt authority\system" /> </operator> </process> <parentprocess> <operator type="AND"> <condition component="Module" property="SignatureType" condition="greaterOrEqual" value="90" /> <condition component="FileItem" property="FileName" condition="is" value="msexchangehmworker.exe" /> <condition component="FileItem" property="Path" condition="is" value="%PROGRAMFILES%\microsoft\exchange server\v15\bin\" /> <!-- This OR operator is to list each possible command line you are seeing. Customize this to meet your needs--> <operator type="or"> <!-- I only had 5 of these -pipe: commands out of thousands of triggerd detections --> <operator type="and"> <condition component="ProcessInfo" property="CommandLine" condition="starts" value="-pipe:" /> <condition component="ProcessInfo" property="CommandLine" condition="ends" value=" -workerListening" /> </operator> <!-- This was the bulk of my detections where no command line was present...but these were also processes which were older than my retention and may not be needed for your environment --> <condition component="ProcessInfo" property="CommandLine" condition="isempty" /> </operator> <condition component="Module" property="SignerName" condition="is" value="Microsoft Corporation" /> <condition component="ProcessInfo" property="ProcessOwner" condition="is" value="nt authority\system" /> </operator> </parentprocess> </definition> As you can see, I am being a bit strict on this exclusion by clearly defining the behavior I want to exclude. This is because this is an exchange server and likely has some portion of itself, exposed to the internet (Email flowing from the internet, OWA, etc...). With the amount of Exchange exploits and zero days found in the past few years (ProxyShell, ProxyLogon, ProxyNotLogon, etc...), I would rather be very clear in what I am excluding on an exchange server. If you have problems making this exclusion working, try commenting out or removing the "SignatureType" and "SignerName" items. If your exclusion only works after that, let us know which EI Server and EI Connector versions you are using.
  16. I think that will be enough info. I have 2 possibilities for you. Both use a parent child relationship. You will see I put a comment in both as you do not need to specify schtasks in the <process> section of the exclusion. Since the rule will only trigger on schtasks.exe, its not needed to include in the exclusion. But my exclusions do ensure your schtasks.exe is being run from expected locations. If all schtasks commands have a single unique item between every execution <definition> <process> <operator type="AND"> <!-- Not needed as rule is already confriming it must be this file name<condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="schtasks"/>--> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="/RU SYSTEM /SC ONCE /ST HH:MM /RL HIGHEST /TR FullPath of program.exe"/> </operator> </process> <parentprocess> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="program.exe"/> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="-some /parent commandline"/> </operator> </parentprocess> </definition> If each execution of your schtasks could have more than one possible command line. Lets say you have 3 different unique parts to a command line. <definition> <process> <operator type="AND"> <!-- Not needed as rule is already confriming it must be this file name<condition component="FileItem" property="FileNameWithoutExtension" condition="is" value="schtasks"/>--> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <operator type="or"> <condition component="ProcessInfo" property="CommandLine" condition="contains" value=" /RL HIGHEST "/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="/RU SYSTEM /SC ONCE "/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="/RU SYSTEM /ST HH:MM /TR FullPath of program.exe"/> </operator> </operator> </process> <parentprocess> <operator type="AND"> <condition component="FileItem" property="FileName" condition="is" value="program.exe"/> <condition component="FileItem" property="Path" condition="is" value="%SYSTEM%\"/> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="-some /parent commandline"/> </operator> </parentprocess> </definition>
  17. For this detection, we need a bit more info to assist in building/recommending an exclusion. Can you provide the following info? Name of executable which is parent to schtasks: Command line which goes with the parent of schtasks: Command line of schtasks process you are starting:
  18. @Mauro Tre Thank you for gathering these final logs. This helped me to confirm my suspicions. There is no sign of any malicious scripts or executables being executed on your system. The on demand scans you are running, are scanning the WMI database and the specific location in the WMI causing detections is the "Windows PowerShell" event log. There are no infections living inside of the WMI database, its just a coincidence that one can access event logs via WMI, which means that ESET can access and scan the event logs via WMI. I am not finding any way to delete specific entries inside of an event log. It looks like Microsoft only allows for all entries to be cleared from an event log. What this means is that in order to stop the On Demand scan from triggering detections, you need to clear the "Windows PowerShell" event logs. Before clearing out the "Windows PowerShell" Event Viewer logs, definitely back them up first. Technically, you already backed them up with the second command I provided previously. Here are the steps to first backup, then clear the "Windows PowerShell" event logs Backup "Windows PowerShell" logs: Copy-Item -Path "$($env:SystemRoot)\System32\Winevt\Logs\Windows PowerShell.evtx" -Destination "$($env:USERPROFILE)\Desktop\ForESET_Windows_PowerShell.evtx" Clear "Windows PowerShell" logs: Clear-EventLog "Windows PowerShell" After this, you should no longer receive detections when running a scan with ESET. Summary of findings from all the logs we gathered: "Windows PowerShell" event viewer logs show logging of multiple PowerShell commands being executed as far back as 2021 ESET installed sometime in 2022 and immediately cleaned up multiple WebShells related to CVE-2021-26855 The above shows that it it is very likely that CVE-2021-26855 was used to remotely plant and execute the WebShells which were executing PowerShell commands that were then logged in the "Windows PowerShell" event logs -Edited- to add one picture showing the link between the ESET scan logs and the Event Viewer log containing the malicious PowerShell command.
  19. @Mauro Tre I have 2 more logs I would like to gather from your computer. This will require you to manually run the 2 powershell commands. First open PowerShell as Admin Next run the following 2 commands Get-WmiObject -ComputerName "." -Query "SELECT * FROM Win32_NTLogEvent WHERE Logfile='Windows PowerShell' AND (RecordNumber=4363 OR RecordNumber=4362 OR RecordNumber=4361 OR RecordNumber=4360 OR RecordNumber=4359 OR RecordNumber=4358 OR RecordNumber=4357 OR RecordNumber=4356 OR RecordNumber=4355 OR RecordNumber=4354 OR RecordNumber=4353 OR RecordNumber=4352 OR RecordNumber=4351 OR RecordNumber=4350 OR RecordNumber=4349 OR RecordNumber=4348 OR RecordNumber=4347 OR RecordNumber=4346 OR RecordNumber=4345 OR RecordNumber=4344 OR RecordNumber=4343 OR RecordNumber=4342 OR RecordNumber=4321 OR RecordNumber=4320 OR RecordNumber=4319 OR RecordNumber=4318 OR RecordNumber=4317 OR RecordNumber=4316 OR RecordNumber=4315 OR RecordNumber=4314 OR RecordNumber=4313 OR RecordNumber=4312 OR RecordNumber=4311 OR RecordNumber=4310 OR RecordNumber=4309 OR RecordNumber=4308 OR RecordNumber=4307 OR RecordNumber=4306)" | ConvertTo-Csv -NoTypeInformation | Set-Content -Path "$($env:USERPROFILE)\Desktop\ForESET_PwshWmiQEventLog.csv" Copy-Item -Path "$($env:SystemRoot)\System32\Winevt\Logs\Windows PowerShell.evtx" -Destination "$($env:USERPROFILE)\Desktop\ForESET_Windows_PowerShell.evtx" This will save 2 files to your desktop ForESET_PwshWmiQEventLog.csv ForESET_Windows_PowerShell.evtx Please run the commands, then zip up the 2 logs on the desktop and provide them here. My theory is that there is no active infection or backdoor. And that sometime in the past, you had malicious PowerShell commands executed on your system, and these were logged to a Windows Event log. Gathering the above logs will help me to verify this and to form a plan to stop ESET from detecting these old event logs.
  20. From looking at the logs provided, you only had detections by an On Demand Scan which successfully cleaned 54 WMI persistent threats. There are no other threats detected by any other part of ESET. From what I can see in the provided logs, your server appears clean. Also of note, ESET Log Collector shows it gathered registry information, but the registry folder is not contained in the provided zip file. This prevents us from performing any checking of the registry. By chance, did you delete this from the zip file prior to sharing here? Can you please elaborate on the symptoms you are seeing after a reboot?
  21. From @Artemis AWAD's description, I made an exclusion (which matches @thae's exclusion). I added some notes to mine to help explain the flow of logic. If this does not work, we will need the following info: Which Rule or Rules are being triggered by these commands? Sometimes you need to add an <operations> section, which is a bit more advanced to create. An example of the Triggering Event Open the details of a detection, and scroll down to the "Triggering Process" section. Provide this as a screenshot and blur out any sensitive data. Notes or Screenshot of Parent to Child relationship If the parent to PowerShell or CMD is always the same, it could be used to make the exclusion more specific. <definition> <process><!-- Single 'OR' Statement which contains a list of processes --> <operator type="OR"> <operator type="AND"><!-- PowerShell Process which can run your PS1 script --> <condition component="FileItem" property="FileName" condition="is" value="powershell.exe" /> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="MyScript.ps1" /> </operator> <operator type="AND"><!-- CMD Process which can run your BAT script --> <condition component="FileItem" property="FileName" condition="is" value="cmd.exe" /> <condition component="ProcessInfo" property="CommandLine" condition="contains" value="MyScript.bat" /> </operator> </operator> </process> </definition>
  22. @3D Joe Ng While hardening your SQL Server is a very good idea, there is a good chance that persistence was already added to the SQL server and that detections by ESET will continue until the persistence is removed. In my last DM to you, I provided a simple way to log SQL persistence. Where you able to run the final batch file I provided? If yes, can you please supply the zip file generated? There are many types of SQL Persistence, and if your MS SQL is hosting more than one instance, each instance will need to be checked. There are the following types of MS SQL persistence: Stored Procedures At start of MS SQL service, a procedure will start and execute ever certain amount of seconds/minutes/hours A stored procedure can be "encrypted" to hide its definition from being easily seen More info on Stored Procedures here: https://blog.netspi.com/sql-server-persistence-part-1-startup-stored-procedures/ Triggers DDL Triggers - Data Definition Language Triggers Server based triggers which can be set to execute when specific queries like CREATE, ALTER, or DROP are used These triggers can be "encrypted" to hide the definition from being easily seen DML Triggers - Data Manipulation Language Triggers Database based triggers which can be set to execute on specific queries like INSERT, UPDATE, or DELETE Untested if these can be "encrypted" but it should be assumed that they can be encrypted as well Logon Triggers As their name implies, these are triggers which execute queries whenever a user logs in to MS SQL. And can theoretically, prevent a user from logging in. Untested if these can be "encrypted" but it should be assumed that they can be encrypted as well More info on Triggers here: https://blog.netspi.com/maintaining-persistence-via-sql-server-part-2-triggers/ Other notes In order to allow MS SQL to execute external applications, the use of advanced options is needed. You will want to check and disable these settings (Ensure you make not of what you changed, and monitor your SQL server for any issues afterwards. Your SQL server may have legitimately been using these settings) "show advanced options" - Allows the following settings to be used "xp_cmdshell" - Allows MS SQL to directly execute external applications like Ping.exe or any other executables on disk. "Ole Automation Procedures" - Allows MS SQL to execute Windows Script Host and VBScript macros, which allows wscript.shell to execute other executables on the computer's disk, without the use of xp_cmdshell. "clr enabled" - Allow you to store .net code inside of SQL which can be executed by a stored procedure. This is one of the more powerful ways of providing code execution to SQL. But these should easily be spotted when reviewing all stored procedures on a server.
  23. I do not recommend simply changing the port any service uses. It is to simple to run a port scan on all ports to identify the service which is running on them and does not stop an attack on any service which is exposed to the internet. It would be better to close easily brute forced ports/services off from any inbound public IPs. If you do need to have the port open to the internet, it should be restricted only to allow specific public IP addresses, otherwise, you will end up having password guessing attacks occur. This holds true for SQL, RDP, SMB, SSH, and many many other services. If you change the default port, and expose it to the internet, you have opened the door to being attacked.
  24. @3D Joe Ng I will be sending you a direct message shortly with some steps to help you move closer to a clean environment. What you have looks to be an MS SQL persistent threat. These are not simple clean up. These occur when MS SQL management ports (1433-1434) are exposed to the internet, and administrative credentials are successfully guessed and used. The way MS SQL persistence works, is that it can execute commands and/or scripts using an assortment of Stored Procedures which will either execute at certain time intervals or when certain actions occur on a SQL server. This can make them feel like they are scheduled tasks. What leads me to believe this is an SQL persistent threat? Its because one of your screenshots shows the main SQL process is involved in causing the detection (.\sqlservr.exe).
×
×
  • Create New...