itman
-
Posts
12,172 -
Joined
-
Last visited
-
Days Won
319
Posts posted by itman
-
-
5 hours ago, matand317 said:
file location is:
C:\Users\user\AppData\Roaming\wow64_microsoft-windows-wow64-legacy_31bf3856ad364e35_10.0.16299.15_none_18ff2b39790378ca
Suspect the other file shown in your alert that begins in Russian? and ends in Microsoft Passport is also bogus and part of the coin miner attack. If the file physically exists on your hard drive, you can submit to Virus Total and see what the scanners their detect.
For the time being until @Marcos gets back to you, you can create a HIPS rule to block startup of anything in "C:\Users\user\AppData\Roaming\*.*". When you create the rule, eliminate the previously shown quote marks. Make you set the logging level to warning, so a log entry is created. If the HIPS log entries created become excessive, you can subsequently set logging level to none. Make sure to post a screen shot of at least one HIPS log page of entries created by the rule. You can then clear the HIPS log if you wish.
As far as I am aware of, there are no executables in C:\Users\user\AppData\Roaming\ sub-directories than run on a normal basis. If in fact you do use Microsoft Passport, make sure there is not a sub-directory created for it in C:\Users\user\AppData\Roaming\. If so and it contains executable files, then don't create the above HIPS rule mentioned
-
What file is Eset detecting the coin miner in? Click on the "file" word shown in blue in the Eset alert to determine this.
-
1 hour ago, COStark26 said:
This Schedule logic contradiction thing is a wide-spread issue. The MBAM Setup screen can show - Recover if Missed by 1 hour - ( implies IF the computer wakes up at "8:00:01 or after" Following a Missed 07:00:00 Scheduled Scan, then Scan.) But 2 Clk's backing out to the Review Screen shows - "Run again Within 1 Hour of Last Miss (implies 07:00:00 asleep / IF the unit awakes between 7:00:01 and 8:00:01 Run the scan. If it doesn't, then DON'T Scan. HOW is that for clear Recover logic?
Interesting assumption.
Also to be factored in to this is how wake up from sleep mode is handled in Win 10. By default you are required to sign-on again after resuming from sleep. Also the subsequent activity that Windows performs is quite similar to that of done when signing in after a full boot; e.g. Win Update check, etc.. This could very well be the problem in that Eset's missed schedule scan internal clock is reset at log-on time.
It has been posted that the missed scheduled scan options also do not work on Win 7. So the issue might very well be that Eset's internal scheduler monitoring clock in regards to missed scans is reset after resume from sleep.
-
I don't understand this posting either. Eset detected the base malware, Win32/Floxif, way back in 2012. Win32/Floxif .H is just a variant which regardless of a positive signature for it which Eset has (created 9-4-2015), would have been detected via DNA signature analysis.
-
I believe the OP's question is if he can use URL's instead of IP addresses in a firewall rule. The answer as far as I am aware of is no.
The problem is Microsoft constantly changes the IP addresses associated with its URLs. Therefore, using IP addresses is an effort in futility.
-
28 minutes ago, Aim2018 said:
What is the difference between known networks and Trusted networks?
Per Eset Help feature:
QuoteConfiguring zones
A zone represents a collection of network addresses that create one logical group of IP addresses, useful when you need to reuse the same set of addresses in multiple rules. Each address in a given group is assigned similar rules defined centrally for the whole group. One example of such a group is a Trusted zone. A Trusted zone represents a group of network addresses that are not blocked by the Firewall in any way. These zones can be configured in Advanced setup > Firewall > Advanced, by clicking Edit next to Zones. To add a new zone click Add, enter a Name for the zone, a Description and add a remote IP address into the Remote computer address (IPv4/IPv6, range, mask) field.
https://help.eset.com/eis/12/en-US/idh_dialog_epfw_zones_page.html
Of note is when the Eset firewall is set to "Public," nothing exists in the Trusted Zone.
-
Proofpoint published an article titled, LCG Kit: Sophisticated builder for Malicious Microsoft Office Documents, which highlights two main points:
1. MS Office malware attacks are becoming increasingly sophisticated.
2. These attacks are now being sold on the dark web as kits enabled those without advanced programming skills to create advanced malware attacks that difficult to detect.
QuoteOverview
Proofpoint researchers discovered “LCG Kit,” a weaponized document builder service, in March 2018. Since we began tracking LCG Kit, we have observed it using the Microsoft Equation Editor CVE-2017-11882 [1] exploit in various forms. More recently, its authors have integrated a VB Script exploit, CVE-2018-8174 [2], which has been used used in limited email campaigns. Finally, at the end of November, LCG Kit added the ability to use Microsoft Word macros instead of exploits to load the shellcode responsible for installing malware payloads.
LCG Kit is somewhat unusual in that the code is highly obfuscated using polymorphic shellcode and a Linear Congruential Generator (LCG) -- an algorithm to generate a sequence of pseudorandom numbers -- to encrypt the final stage of the code, including the payload locations. We named LCG Kit due to this unique feature.
Due to the widespread appearance of malicious attachments created with LCG Kit in a number of email campaigns,, we presume that it may be for sale on underground forums. LCG Kit appears to be popular with small crimeware groups for spreading Remote Access Trojans (RATs) and stealers including Loki Bot, FormBook, Agent Tesla, Remcos, AZORult, Revcode RAT, Quasar RAT and more in campaigns that typically involve thousands of malicious email messages. Colleagues at Cisco Talos described one such campaign in October [4].
History
Proofpoint first observed documents that appeared to be built using this kit in the middle of March 2018, delivering Loki Bot.
The kit appears to have several possible target documents :
- RTF documents
- Microsoft Word/Excel 2007+ documents (often read-only or protected) with OLE objects containing the Equation Editor code
- PDF documents with JavaScript loading an embedded RTF document containing the exploit
- Microsoft Word/Excel 2007+ documents with embedded remote RTF objects containing the exploit
It is therefore imperative that organizations employ mitigations to defeat the above attack methods. I posted previously about OLE mitigations. JavaScript should be disabled via in-product Adobe Reader setting, RTF objects should likewise be blocked via MS Office in-product settings. Etc,, etc.
-
Quote
System Requirements
Supported browsers: Internet Explorer (8.0.0.0+), Chrome (30.0.0.0+), and Firefox (24.0.0.0+).
https://support.eset.com/kb5657/?locale=en_US&viewlocale=en_US
Also noted in the article is for best compatibility with BP&P, it is recommended that you set your default browser to IE11.
-
4 hours ago, ShaunWilliams said:
I did see the twitter post yesterday and there is a difference between .Nano and .nano.
Also, Rapid 3.0 Ransomware uses the .nano extension. So it is imperative the ransomware be positively identified which can be done here: https://id-ransomware.malwarehunterteam.com/
-
If this is Scarab ransomware, this is a very recent variant:
QuoteMichael Gillespie @demonslay335 Dec 28
#Scarab#Ransomware using extension ".nano" (note the difference with Aurora's ".Nano" - case matters!). ID Ransomware can detect the difference. Encrypted key in the ransom note is at the very bottom after a ton of newlines. -
Microsoft has an article on firewall ports and connections used by Visual Studio: https://docs.microsoft.com/en-us/visualstudio/install/install-and-use-visual-studio-behind-a-firewall-or-proxy-server?view=vs-2017 .
One easy solution might be to just switch the Eset firewall to its default allow all outbound connections when performing your debugging activities.
-
This is a long shot suggestion but the process crashing activity might be related to a known 1809 bug in which desktop notifications are not working after the 1809 upgrade. This would be more the case if you are no longer receiving any Win notifications after the 1809 upgrade. If this is the case, you could try this fix: https://pureinfotech.com/fix-action-center-notifications-not-working-windows-10-1809/ or Google search for other fix suggestions.
The missing desktop notifications was really the only issue I encountered after upgrading to 1809, and the above posted link fix worked for me.
-
8 hours ago, horion70 said:
This warning appears until you clear the log. Maybe its a new feature. You can still click apply to disable the protection.
Interestingly today when I went to pause Eset protection, I received the normal alert with specification on how long to pause for. So it appears, my posted screen shot is a one-time thing.
Anyway, I paused Eset w/o issue. No ShellExperienceHost.exe crash or anything else for that matter. So I can't duplicate the issue on my Win 10 x(64) 1809 build w/EIS 12.0.61 installed.
Again, this ver. of Eset was installed on 1803 when I upgraded to 1809. What is a fact is I had multiple failures trying to upgrade to 1809 via Win Updates download. What I finally did was disable Virtualization in my BIOS settings which in turn disabled Core Isolation in 1803. I then did an in-place upgrade to 1809 as previously described. What I can state is as a result of this in-place upgrade, 1809 has been running w/o issue. In fact, it has been the most problem free Win 10 upgrade I have done to date.
-
2 hours ago, novice said:
So, what's the point of such a test??? Is this the methodology followed by AV Comparatives??? Was ESET disconnected from LiveGrid during AV Comparatives test?
So, again this proves nothing...
In theory, KIS 2019 should have performed better than EIS 12.0.31 in this test because it already has behavioral monitoring; i.e. System Watcher, in place. Note that EIS/NOD32 doesn't have behavioral monitoring until ver. 12.1.
As far as no Internet connection, it would have no effect on detection in this test since neither product goes to the Cloud to perform to decision making activities to block or allow the malware process from running.
-
16 hours ago, horion70 said:
The crash in ShellExperienceHost mostly happens when temporary disable and then enable eset
Just tried to duplicate this on Win 10 x(64) 1809 w/EIS 12.0.31 installed.
When I tried to disable Eset, I get what is shown in the below screen shot:
Never ever saw anything remotely similar to this on any prior version of Eset I have installed. Also, the date of last threat detection in my Eset corresponding log file is 12/21.
-
50 minutes ago, Marcos said:
Just out of curiosity, I've installed KIS 19 on Windows 10, fully updated it and then disconnected the VM from network for security reasons. Then I copied recent (3-4 hours old) Filecoder.Crysis and Emotet trojans detected by ESET and ran them. None of them was detected / blocked and both were executed. I didn't cherry pick them, just took random infamous recent malware.
To satisfy "our friend" uninstall KIS 19 so that only WD is running. Make sure its signatures are updated. Leave Controlled Folders and other settings at default. Rerun the same samples and see if anything is encrypted or if Emotet was detected.
-
This issue is a mystery to me since I am running Win 10 x(64) and EIS 12.0.31 w/o such problem.
I suspect this might be related to how the Win 10 1809 upgrade was performed? I performed the upgrade by doing an in-place upgrade from 1803 using a prior 1809 .iso file downloaded using the MediaCreator tool.
I would suggest opening an admin level command prompt window and run this command:
DISM.exe /Online /Cleanup-image /Restorehealth
This will run for a while and will fix any system issues it finds with your 1809 build.
-
As far as AV lab malware sample selection goes, I believe it is logical to assume some qualification of samples is used. Besides the obvious selection by malware category; e.g. Trojan, ransomware, etc., it can be assumed that prevalence is also a factor. If a lab always used the most prevalent samples, the tests would show almost always show 100% detection by most of the major AV vendors. Obviously, a widely used malware is one that needs immediate detection and mitigation. Additionally if lab test reports showed always 100% detection by all test participants, no one would pay attention to the tests since they already know the outcome. AV vendors would no longer pay to have their products tested and the labs would go out of business.
So if is fair to assume that the labs will include a few malware samples that are not widely in use or are isolated geographically. The odds of one being infected by one of these malwares is statistically very low. Assumed is Eset is concentrating on malware with the greatest risk to its customers versus trying to "bag" a lab test with a 100% score. Finally do note that AV labs do not disclose such sample selection criteria as above which really needs to be done.
-
On 12/26/2018 at 11:11 AM, Marcos said:
red are unhandled threats
Could you please elaborate on just what this means? For me, it means Eset didn't fully handle the threat and further user action is required.
I asked this same question in another thread and really didn't receive what I consider a full explanation. In my case, it was a web based browser javascript detection; ref. here: https://forum.eset.com/topic/17986-detected-threat-shows-in-red/ . The alert Eset generated states "Threat removed" and "The file has been cleaned." Also there is no required user interaction for the threat. I interpret this to be the threat was fully mitigated by Eset. Is this a correct assumption? If so, why are the threat detections shown in the Detected Threats log as red versus yellow?
-EDIT- I always forget that that I have "strict cleaning" enabled for all realtime ThreatSense selections other than for PUA. So it appears that "red" indicates Eset detected and removed the threat without performing any further activities such quarantining it, displaying user threat handling options, etc.. So in essence Eset didn't "handle the threat," it wiped it out instead.
-
As far as the GrandCrab 5.0.4 ransomware, what was submitted to Hybrid-Analysis was a binary file, 05bfd83bb0d4e7d27bbfc2c057b2b692612de808cc4bca73d9e0ae1d9d479623.js.bin. This leads me to believe the original source of the ransomware was a MS Office Word .doc file employing this for example: https://cloudblogs.microsoft.com/microsoftsecure/2016/06/14/wheres-the-macro-malware-author-are-now-using-ole-embedding-to-deliver-malicious-files/ . So blocking all script child process startup including PowerShell from MS Office executables would have prevented the ransomware from running. Also do note the Microsoft recommended mitigation to block OLE automation in MS Office.
-
40 minutes ago, Tornado said:
Downloaded the first sample with very few detections on VT and ESET picked it up as JS/TrojanDropper.Agent.NQS and the second link shows that ESET already detects it. Don't forget that ESET Advanced Memory Scanner would likely detect it as soon as it decloaked in memory.
Kudos to you for testing it. I suspected the same originally since not all of Eset's protection mechanisms are fully functional on VT. But again, one is not fully sure of detection without a test.
-EDIT- Also appears that a variant detection for this was added 5 hours ago via signature update 18609: https://www.virusradar.com/update/info/18609 .
-
1 hour ago, MarcoO said:
why using a third party AV like for example ESET over MS Defender?
Without getting into a long discussion on WD's deficiencies, its biggest flaw is that it can be easily disabled/modified by an attacker. Whereas Microsoft has finally tried to mitigate this by sandboxing portions of its kernel/engine process, it remains to be proven through penetration testing it can't be bypassed.
-
14 hours ago, BALTAGY said:
NVM i made it, since i don't use PowerShell i made a rule to ask if any app want to run it
Let me begin with it is almost impossible to stop malicious use of PowerShell by a determined attacker. One might think that creating a HIPS ask rule to monitor the startup of C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe and C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe will detect all PowerShell execution. It won't.
Past examples of malicious use of PowerShell include to name few:
1. The attacker downloading the old version of PowerShell, ver. 2.0, used in Win 7 and running it. This version for example, will run fine on Win 10 as long as .Net 2.0 or 3.5 is installed.
2. Downloading the current ver. of PowerShell to any directory, possibly renamed but not necessary to do so, and running it from that location.
3. Executing .Net subassemblies associated with PowerShell via C#, C, etc. program means.
The only way to completely stop PowerShell execution would be to employ a security product that can block execution by hash value and then create ask/block rules for hash values associated with every known version of PowerShell. Also, setting PowerShell to Constrained Language mode or using AppContainer which does the same.
Eset has a few knowledgebase articles on PowerShell and other script use mitigations:
1. Firewall rules: https://support.eset.com/kb6132/
2. HIPS rules: https://support.eset.com/kb6119/
These will prevent the most prevalent malicious use of PowerShell. They will not prevent all malicious use of PowerShell.
-
1 hour ago, BALTAGY said:
An example:
https://www.virustotal.com/#/file/05bfd83bb0d4e7d27bbfc2c057b2b692612de808cc4bca73d9e0ae1d9d479623/detection
I know it's a new Ransomware but it could be detected by now ?This one is GrandCrab ransomware. Suspect the javascript payload is heavily obfuscated. Such has been the "Achilles heel" for AV's for some time.
If you look at the Behavior section on the detection at VT, it is running PowerShell. One reason among many I have a HIPS rule to monitor all PowerShell execution.
Think I have a virus that won't go away plz help
in Malware Finding and Cleaning
Posted · Edited by itman
Also per Virus Total: https://www.virustotal.com/en/file/1d6965edad78dbaa59f02a24b98e4bb6ad3fafbd8b51aaaeee43c1dd8f8c7315/analysis/1534723852/ , this appears to be XRIG Monero coin miner based on the Eset malware detection. This coin miner is known to exploit vulnerable Win OS versions. Is your system fully up to date OS update wise?