itman
-
Posts
12,466 -
Joined
-
Last visited
-
Days Won
329
Posts posted by itman
-
-
Do you have Eset installed?
-
Question to anyone with this issue. Is the CD/DVD a USB one?
-
1 hour ago, Marcos said:
I opened https://ibanking.stgeorge.com.au/ibank/loginPage.action in Firefox and was asked if I want to open it in a secure browser.
Such is not the case in IE11.
-
This Eset knowledgebase article also has a few additional recommendations in regards to best practices against ransomware: https://support.eset.com/kb3433/?locale=en_US&viewlocale=en_US
-
https://www.us-cert.gov/ncas/alerts/AA18-337A
I have copied the recommended mitigations with sections underlined for emphasis:
QuoteMitigations
DHS and FBI recommend that users and administrators consider using the following best practices to strengthen the security posture of their organization's systems. System owners and administrators should review any configuration changes before implementation to avoid unwanted impacts.
- Audit your network for systems that use RDP for remote communication. Disable the service if unneeded or install available patches. Users may need to work with their technology venders to confirm that patches will not affect system processes.
- Verify that all cloud-based virtual machine instances with public IPs have no open RDP ports, especially port 3389, unless there is a valid business reason to keep open RDP ports. Place any system with an open RDP port behind a firewall and require users to use a virtual private network (VPN) to access that system.
- Enable strong passwords and account lockout policies to defend against brute force attacks.
- Where possible, apply two-factor authentication.
- Regularly apply system and software updates.
- Maintain a good back-up strategy.
- Enable logging and ensure that logging mechanisms capture RDP logins. Keep logs for a minimum of 90 days and review them regularly to detect intrusion attempts.
- When creating cloud-based virtual machines, adhere to the cloud provider’s best practices for remote access.
- Ensure that third parties that require RDP access follow internal policies on remote access.
- Minimize network exposure for all control system devices. Where possible, disable RDP on critical devices.
- Regulate and limit external-to-internal RDP connections. When external access to internal resources is required, use secure methods such as VPNs. Of course, VPNs are only as secure as the connected devices.
- Restrict users' ability (permissions) to install and run unwanted software applications.
- Scan for and remove suspicious email attachments; ensure the scanned attachment is its "true file type" (i.e., the extension matches the file header).
- Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
-
1 hour ago, Marcos said:
Do you have the option shown in my screen shot enabled or disabled?
Disabled.
I thought it wouldn't matter what that setting was since my prior use of Application Modification showed it was only applicable with the firewall in Interactive mode. Again the only alert I have ever received was for equi.exe. What is strange is the alert doesn't manifest until a few hours after an Eset upgrade. And the alert only occurs once after I respond with keep existing firewall rules. For example, Eset upgraded to 12.0.31 at 9:00 AM today and the alert appeared late in the afternoon. Also there has been no change to equi.exe last modification date after the above noted upgrade time.
-
5 minutes ago, Marcos said:
This would happen if you had a permissive firewall rule created for egui.exe
The only firewall rule for equi.exe is the default rule. See the below screen shot. Should that rule be disabled?
-
I assume you are trying to remove SEP?
Did you try this: https://support.symantec.com/en_US/article.HOWTO74877.html
-
I have had the below screen shot alert occur the last few times an Eset in-product upgrade occurred. I have the firewall set to Automatic. I thought Application Modification detection only occurred when the firewall was set to Interactive mode. Also this is the only app update alert I every receive. The Eset GUI default firewall is enabled allowing all equi.exe outbound traffic.
Is this some type of internal security check to detect any unauthorized equi.exe modification?
-
20 minutes ago, ISHOULI said:
ESET devrait se concentrer sur le pare - feu pour assurer une protection contre les fortes inondations et attaque DDoS
Et quand quelqu'un vous donne l' inondation l' internet sera détecté et arrêté automatiquement sans que vous fassiez rien
This is an English language forum. Please post in English if you expect to get any replies.
-
There is one "glitch" I found in regards to in-product Eset upgrades.
If you perform an Eset repair installation via Control Panel -> Uninstall Programs option, Eset reverts back to the last version that was off-line installed. For example if you manually installed Eset ver. 11 and in-product upgraded to ver. 12, after the repair installation, you're back to ver. 11. You then have to perform an in-product upgrade to get to the latest Eset version. I find this very odd behavior.
-
10 hours ago, kingsyno said:
My client server with ESET installation on it just had similar issues. Please what do we do?
If it's GrandCrab ver. 1,4, or 5, you can try this to see if will decrypt the files: https://www.nomoreransom.org/en/decryption-tools.html#GandCrabV1V4andV5versions
Additional reference is here: https://www.europol.europa.eu/newsroom/news/pay-no-more-universal-gandcrab-decryption-tool-released-for-free-no-more-ransom
-
Let's get back to the methodology employed in this test namely:
Quotethe Python script only plays the role of executing the malware in the ./Phase1 and ./Phase2 folders. It it NOT a ransomware. It's called malex for a reason (MALware EXecutor)
There are only three ways a Python script can be executed on a user device:
1. The user manually installed Python.
2. The attack involved downloading Python and installing it.
3. As posted previously, the attacker created an executable with the Python engine component and malicious script contained within.
Methods 1). and 2). are not viable scenarios since most users do not install Python and malware installation of it would be extremely "noisy."
That leaves number 3). as the most likely way Python based malware would be deployed. And this method needs attention by Eset and other AV vendors. Also this is not an easy mitigation in that the presence of the Python engine code within the .exe is in itself not malicious. It is the code within the script that is malicious. And, it is a given that the script code will be hidden and will not reveal itself until the executable unhides the script code in memory prior to executing it via the Python engine. Compounding the issue is Python scripts cannot be examined by the Win 10 AMSI interface when executed this way; even if it did so which BTW, it does not. This leads to two possible detection scenarios:
1. Improved sandboxing analysis for any executable that contains Python engine code remnants and detection of script code malware after it is unhidden in memory.
2. After sandbox detection of Python engine code remnants, alerting the user of possible suspicious process activity. This alerting could be conditioned upon a number of factors such as process reputation status; e.g. unknown, signing status; e.g. unsigned, etc..
I believe number 2). is the only viable solution given the capability of Python script code executed this way. Also it is not the norm for legit application software to be developed this way.
-
15 hours ago, itman said:
Or is what we have here is a polished presentation using a pre-evaluated ransomware sample that my sponsors product detected but its major competitor did not?
To clarify, what I was trying to suggest is this and like activity is possible in ad hoc testing; not that it actually occurred. I have no direct proof that TPSC engaged in such activity.
-
4 hours ago, Buzzle said:
Second, the reason why Kaspersky only get a Pro-active detection ratio of ~80% but still pass Phase1 is due to the fact that BOTH HitmanPro and MalwareBytes detect nothing after Phase 1
Perhaps the non-detection is due to the fact both products have shown issues with malware detection in AV lab testing? Malware Research Group up until recently used to include both products in their quarterly 360 Full Spectrum tests: https://www.mrg-effitas.com/wp-content/uploads/2018/05/MRG-Effitas-2018Q1-360-Assessment.pdf
-
1 hour ago, ECELeader said:
Although The PC Security Channel [TPSC] is not an official AMTSO member, it is a worth noting channel that uses a consistent methodology to test security products.
That said, I see a few "irregularities."
TPSC has affiliations with Bitdefender, Kaspersky, and Sophos. Next as show in the below screen shot, Kaspersky only scored in 80.46% versus Eset's 95.6% in Phase 1 testing but passed overall testing? Appears that because Eset failed the Python ransomware test that was justification for the overall failure rating. Is this a standard AV lab testing methodology? Or is what we have here is a polished presentation using a pre-evaluated ransomware sample that my sponsors product detected but its major competitor did not?
-
AV-Comparatives has a write up on uTube security test sources. The most important point to note is these concerns are not formally recognized AV lab testing sources. As such, they don't adhere to formalized and verifiable testing standards.
QuoteBelow are some YouTube tech channels that readers may find interesting. Please note that by making these links available here, AV-Comparatives does not necessarily agree with any methods or opinions expressed in any of these channels, and does not necessarily endorse (or criticise) any products or services mentioned in them. Readers should employ their own judgement when considering the validity of any points expressed by the channel’s authors.
As its name suggests, this channel focuses very much on PC security.
This covers Windows and Mac platforms, and covers maintenance as well as security.
The emphasis here, as suggested by the name, is protecting computers from malware.
This is another malware-oriented channel.
Actual tests of antimalware programs, against phishing and malware URLs and other threats, are demonstrated in this channel.
A series of regular interviews, discussing various security related issues.
German-language channel with videos on individual security flaws, tips and tricks.
-
3 hours ago, Marcos said:
I will check with my colleagues if we are aware of this test and if was performed according to AMTSO standards
Doubt this is the case.
From what I can determine, PC Security Channel is not an AMTSO member: https://www.amtso.org/members/
This test falls into the category of all ad hoc Internet tests whose results cannot be verified and therefore should be ignored. The only exception I can think of would be Runbenking's PC Magazine tests employing the Core Impact tools. He has been doing those for years and is very upfront on how and what he tests for.
-
1 minute ago, Rami said:
But it was running through PowerShell
This is immaterial per se. Although I do have a HIPS rule to monitor all PowerShell execution. Also, Eset has a KB article in regards to PowerShell HIPS rule monitoring as it applies to FileCoders.
-
I will say this.
If traces of the Python engine code are detected in an .exe, Eset should flag that .exe as suspicious.
-
As far as the first test phase, the malware .exe's were dropped in %AppDataUser% directories. So I don't know why those weren't detected. I personally have a HIPS rule that monitors any process startup in those directories.
As far as the Python based ransomware, it first needs to be verified if the tester had previously installed Python on the test rig. If so, then running of a malicious Python script would be much easier to accomplish. Note that the average user would not be installing Python.
Now there are malware attacks that can download the Python engine "on the fly" with a malicious script. However, this requires the previous to be "bundled" in a .exe. If the script was encrypted, obfuscated, packed, etc.., it would be hard to detect in memory since Win 10 AMSI interface does not scan Python scripts.
-
Well, that didn't work. Only God knows what the heck Microsoft is doing to initiate the ICMP outbound connection. So I am just allowing that single IP address for the time being.
-
@Marcos, fairly certain I have identified the source of the alert. Alert time corresponds to startup of a scheduled task running sedlauncher.exe that was installed courtesy of KB4023057. This bugger is Microsoft's monitoring of Win10 1803 for suitability to upgrade to 1809.
When the alert appears is there a way to create an exception by process name?Never mind, found out how to do so. -
12 hours ago, axlgabo10 said:
In short, with ESET can not block or eliminate this service?
I have the same problem of infection in a client
Yes it can detect it if PUA protection is enabled.
PUA protection is most effective at software installation time. Possibly the concern overrode the PUA alert?
In any case, have the concern run a full system scan with Admin privileges.
Windows Firewall Blocking Ekrn.exe?
in ESET Internet Security & ESET Smart Security Premium
Posted
Win 10 Home x(64) 1803, Internet Security 12.0.31
For the first time ever, saw the below Event Log entry today after cold boot. Everything system and Eset wise appears to be OK and functioning normally. Boot was extremely slow however. Might be just a startup glitch due to Windows Security Center not fully initialized?