itman
-
Posts
12,197 -
Joined
-
Last visited
-
Days Won
321
Posts posted by itman
-
-
17 minutes ago, winstonsmith84 said:
The struts exploit is for Apache but the server listed in the threat log doesn't have Apache installed on it. So why would this be listed as a threat alert on this server?
I am wondering if Eset is detecting an old unused Apache app on the server?
QuoteUnfortunately, fixing this critical flaw isn't always as easy as applying a single update and rebooting. That's because in many cases, Web apps must be rebuilt using a patched version of Apache Struts. For older apps, developers may need to exhume long-forgotten source code and test the finished binary to make sure it doesn't break the rest of the website it's hosted on. Apache Struts is a framework for developing Web apps based on Oracle's larger Java framework. Struts has slowly been phased out in favor of newer developer tools, but it remains used by a significant number of banks, government agencies, and Internet companies.
-
30 minutes ago, winstonsmith84 said:
One is SMB/Exploit.MS17-10.B
As far as this one goes which is related to the NSA exploits; i.e. EternalBlue, etc., refer to this: https://support.microsoft.com/en-us/help/4023262/how-to-verify-that-ms17-010-is-installed
-
24 minutes ago, Rami said:
Might be the reason of that there are less malware analysis employees at the weekends as Marcos said :
Again, the issue has nothing to do with how frequently Virusradar database signatures are created. The frequency on the weekends is the same as on week days as best as I can determine.
The issue is how often those signature updates are distributed to Eset update servers worldwide. For some unknown reason, it appears the Eset update server assigned to North America is not receiving these updates promptly on the weekends. Or, the server is off-line for an excessive period of time on the weekends.
-
This is interesting. The IP address, 51.15.90.178, associated with the URL blacklisted is in Paris, France and appears to be associated with a gov. web site; UK Government Department for Work and Pensions. A UK gov. web site hosted in France?
In any case, a web connection from C:\Windows\SysWOW64\dllhost.exe definitely is not normal. For the time being, you could create an firewall rule to block all TCP/UDP traffic inbound/outbound for IP address 51.15.90.178. Once it is determined what is causing the dllhost.exe traffic, you can delete the firewall rule.
-
As far as CVE-2017-5638 goes, this vulnerability was disclosed in 3/2017. Reference here: https://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html . You need to upgrade Apache to the latest version.
-
2 hours ago, Moneesh said:
I don't know what application in my PC is trying to access this website.
If you expand the "Application" column in the log, it will show you the full path name for the source app Eset is detecting.
Eset also shows the source app in the desktop alert generated if you click on the "Details" section in the alert.
-
3 hours ago, Marcos said:
What would not be ok if the engine constantly doesn't get updates after more than an hour.
Well, this is my case since my average update time is 3 - 4 hours. On the other hand, new sig. updates are shown with like corresponding frequency on the Virusradar database web site. So I never was concerned about this interval. It is when I receive updates than are greater than 4 hours in frequency is when I get concerned. And this always occurs on the weekends for some reason.
-
5 hours ago, Marcos said:
To find out, this will require troubleshooting if you can reproduce the issue.
I know the update checking is working properly since I see the time being updated in the Eset GUI. The connection to Eset update servers is being made since I see the Eset update server URLs showing in my network connection monitor.
My last sig. update today was 12:54 PM EST. It is now 7:22 PM EST and the manually update check is now not pulling down the latest sig. update. And again, this is typical Eset weekend update behavior for me.
-EDIT- I cleared the update cache and was able to manually download the latest sig. update.
-
3 hours ago, Marcos said:
Why shouldn't be? There are far less detection engineers on duty during weekends but that's not a problem since the amount of new malware during weekends and fests is very low. Malware writers also take time to rest.
That is not the issue.
Using Eset's Virusradar web site as a reference: https://www.virusradar.com/en/update/info/ , the 18735 signature update was created at 1/19, 22:00 CET. That equates to 15:00 EST my time. I still had not received the update at 19:00 EST when I then forced the update manually.
If Eset checks for updates on an hourly basis, why was it not pushed to my installation at 16:00, 17:00, or 18:00 EST? That is my question.
-
I just checked mine and it was 18734 with the last update 5 hours ago. I agree that is way to long for an update to be delivered. I just did a manually update to 18735. BTW - you don't have to do a system restart to do so.
Eset checks for updates hourly. So I really don't know why these update cycles are so long on the weekends.
-
There is another work around for this problem.
You can create a .bat script containing Eset's command line ECLS scanner as shown here: https://support.eset.com/kb3417/?locale=en_US&viewlocale=en_US . Then create a scheduled task using Windows Task Manager to run the script. Assumed is you need to set the scheduled task to run with highest privileges.
-EDIT- Also in regards to using the coding shown in the KB article in a .bat file, I believe you need to add leading and trailing quotes to the entire string as shown below:
""c:\Program Files\ESET\ESET Smart Security\ecls.exe" /base-dir="c:\Program Files\ESET\ESET Smart Security" /auto /log-file=c:\ecls.txt /aind "
-
2 hours ago, TrialUser said:
Sorry to be so dense, but I see there are several protocol parameters in advanced setup, and they have to do with email and web access. Are these the ones I should try disabling? Which ones? Thanks again.
See the below screen shot. Uncheck the circled field and click on OK to save your changes. Make sure to reenable the field after you are done testing.
-
43 minutes ago, COStark26 said:
Not crucial to the issue BUT - I read 6:00:15 PM to be 6 PM - 0 Minutes - and 15 Seconds (ie) 15 seconds past 6 PM. No?
Correct. I stated so incorrectly. It shows seconds; not thousands of a second.
-
My above posting of using thousands of a sec. in scheduled time field also did not work in starting of the scan upon resume from sleep mode.
Appears the only immediate solution to this issue is to set scheduled time to a time when PC is always powered on. Or, just initiate the scan manually.
-
To get to the bottom of this, I went to the Apower web site here: https://www.apowersoft.com/phone-manager and downloaded apower-manager.exe.
I then performed an Eset context-menu scan on apower-manager.exe in my Downloads folder. Results shown below:
I then performed an Eset context-menu scan on the Downloads folder. Results shown below:
The bottom line is apower-manager.exe shows no malware by either context-menu scan method; individual file or folder. Therefore, I can't duplicate the activity you posted about.
-
1 hour ago, Tino said:
Sorry but I still don't quite get what you said. First, you're talking about an "original archive". I believe that I did not even download an archive (i.e. zip file, correct?) but rather downloaded the exe file directly.
Thanks for the clarification.
Based on your above context-menu folder scan screen shot, apower-manager.exe is an installer. Note the "INNO" reference shown. More detail on that here: https://en.wikipedia.org/wiki/Inno_Setup . When Eset scanned the installer for files contained within, it found an archived(ZIP) file containing apower-manager.apk which it classified as Trojan based malware.
Why Eset did not the same detect Trojan when performing a context-menu scan on apower-manager.exe itself, my best guess is you did not clean the Trojan at the end of the previous folder scan? Eset internally recorded this decision for the file and did not redisplay the Trojan status.
What I would do is delete apower-manager.exe in your Downloads folder. Then download it again from your original source web site. Now perform an Eset context-menu scan on the downloaded file and see if Eset detects the same Trojan as shown previously.
-
7 minutes ago, TomFace said:
I have had no issue whatsoever seeing the "Refer a friend" on all gui screens since day 1.
I reside in the U.S. and it occurred the very first time for me with a EIS 12.0.27 download. And again as posted, the option a while later did start appearing in the GUI.
-
3 hours ago, Marcos said:
@itman, what issue did you meant by saying " I thought by now Eset would have fixed the installer issue" ?
The "Refer a friend" option missing from the Eset GUI. Perhaps this occurred in the ver. 12.0.31 installer @Moriseif downloaded because it was not fully activated as you posted above?
-
I will say this about this software, I would be leery of using it personally.
Here is a sample named apower-manager.exe that was submitted to Hybrid-Analysis last year: https://www.reverse.it/sample/6db7d567d84c205ad90c3924e120acea2c73d3830f631be87de613f2d4e5f539?environmentId=100 . It determined that it was 100% malicious. However, every vendor listed at VirusTotal determined the sample was clean.
I would submit your apower-manager.exe to Hybrid-Analysis for a scan and see what it finds.
-
6 minutes ago, Moriseif said:
Did u install new one?
Right now install with latest version (12.0.31.0) and again have a problem with that ...
No. I did an in-program upgrade to 12.0.31 and the option remained in place after the upgrade completed.
Strange .……. I thought by now Eset would have fixed the installer issue; at least on ver. 12.0.xx. I assume this is a matter of priorities with this issue being a non-operational one, assigned a low fix priority.
-
As far as I am aware of this issue has been resolved. Eset a while back appears to have issued a module update for ver. 12.0.27 since I now see the option on my Eset GUI home page.
-
I believe I know what is going on here although the Eset log entires are in German.
You have both the original archive and a subsequent extracted .exe from it present in the Downloads folder. Assuming you have ThreatSense set to Normal scanning, it is detecting apower-manager.apk as the Trojan component. It could not clean the archived version of it for some reason and only will block the extraction of it. If Strict cleaning was deployed, I assume Eset would have just deleted the entire archive.
It appears the extracted executable, apower-manager.exe is clean, hence no Eset scan alert for it. You can verify this by submitting the file to VirusTotal to see if any of the AV engines used there detect it as malware.
-
This one has been bugging me for a while. Eset HIPS default behavior for ask rules that have not received a user response is allow. This is the only HIPS I have used where like default behavior is not block.
Before I get into my suggested enhancement in this regard, overall I agree with Eset's approach. It is designed to prevent a user from creating an ask rule that due to;
- Eset GUI not fully initialized at boot time
- Non-response due to user physically not present at device
that could inadvertently lead to critical system/app function being blocked leaving the system inoperable.
However, the fact remains that the default allowed activity could have been malicious or suspicious in nature and needs user review.
I therefore propose the following HIPS enhancement as far as default allow ask rule activity:
1. All such ask rules are logged in the HIPS log.
2. Eset display a non-expiring desktop alert that such default activity has occurred. At boot time, this could be done after the Eset GUI is fully initialized. The alert does not have to more than a notification that such default behavior occurred.
This would alleviate one constantly reviewing the HIPS logs for such activity assuming he previously set logging to the correct level to capture such default activity.
-
A security analyst a while back wrote a blog posting about Barkley's Stackhackr simulator . The blog is titled 'Security Through Absurdity'.
I am posting excerpts below but you really should read the entire article. Overall, chalk this one up as more Next Gen marketing FUD:
QuoteStackhackr; Useless for Testing – Good for Marketing
Barkley, a self-proclaimed security company, has revived the 1990’s era Rosenthal Virus Simulator; an application that called false positives good while claiming to test the quality of antivirus products. Some users believed that this simulator indicated if an antivirus product was good at detecting malware. As a result some AV companies wrote detection specifically for Rosenthal’s harmless files. The customers wanted harmless false positives for harmless files and so they got them.
Barkly has come out with a free product they call stackhakr. Stackhackr is a lead generation application that is disguised as a security product testing tool. In reality it is another Rosenthal type program that convinces users that false positives mean better security.According to Barkly “The malware you create won’t actually cause any harm, but whether it runs or gets blocked will tell you if your system is vulnerable to the real thing.”Really? If a completely ineffective security product writes detection specifically for this application then you are not vulnerable to the real thing? If a product false positives and detects your harmless files, then the company’s customers are not vulnerable to ransomware?Stackhakr does not test the ability of a product to detect ransomware, malware, or the ability of a product to effectively deal with any attacks. Due to the security effectiveness of application reputation Barkly specifically calls out this type of detection as a false positive. Barkly claims that detection of their launcher application is a false positive because the launcher file is harmless and not part of the test. Seriously? Detecting a harmless launcher is a false positive but detecting the harmless files it writes is not?
HIPS filtering modes
in ESET Internet Security & ESET Smart Security Premium
Posted
Your best protection against financial malware is to perform all like activity in Eset Banking and Payment Protection feature. As far as keyloggers go, you're covered since BP&P scrambles all your keystrokes. The HIPS per se has no dedicated keylogger protection. The HIPS option of global hook detection, i.e. global keylogging, only works in XP as discussed in a past forum posting. Don't know if that has been changed in regards to latter OS versions but doubt it.
As far as the HIPS learning mode, you leave it enabled as long as it takes to create rules for your normal system activities. Then you switch the HIPS to interactive or policy mode. In policy mode, the HIPS blocks anything that does have an allow rule associated with it.
You will also have to manually switch back to learning mode whenever you install anything or perform Win updates. Also Win 10 store apps could be problematic since they are constantly being updated with new program names being generated for most of them.