Jump to content

itman

Most Valued Members
  • Posts

    12,102
  • Joined

  • Last visited

  • Days Won

    319

Everything posted by itman

  1. Also worth researching is if this new method of malware persistence currently being employed by the NanoCore Trojan was used by this ransomware. Note the suspended process activity in the video: Ref.: https://www.zdnet.com/article/nanocore-trojan-stops-you-killing-its-process/
  2. Personally, I never was concerned about unsolicited incoming echo reply request since my router's firewall blocks them by default. As far as Eset goes, I have it set to defaults in regards to Known Networks; i.e. use Windows Settings. The Win firewall is set to Public profile. Also for the record, the Eset default inbound firewall rule for ICMP IPv4 does not specify Trusted Networks in its Remote setting field. This would be the proper setting for the other ICMP protocol settings other than Echo Reply. Bottom line - you have a bug in that default ICMP rule. -EDIT- Actually, it doesn't matter if external incoming echo reply requests are allowed since Eset will only allow corresponding outgoing echo reponse requests from the Trusted Network. The only concern would be an ICMP flood attack which Eset's IDS will detect and alert.
  3. Create a HIPS rule to allow cleanmgr.exe to write to and delete files in C:\Users\xxxxxx\AppData\Local\Temp\*. It worked for me in allowing DISM to run w/o issue since I also monitor any process startup activity in AppData directories.
  4. I reviewed the video again and said to myself, "Sometimes the obvious alludes you." This is not an RDP attack but rather a misguided attempt at a remote execution attack. In a RDP attack, the attacker previously gains the targets logon credentials. Then from a device external to the targeted network and device within, logs on to the targeted device from his external device using the RDP protocol. A remote execution attack occurs when "dropper" program is unwittingly downloaded to a target network/device. The purpose of the dropper is to create usually a "backdoor" through which the attack can either download additional malware to the target device and/or run the malware remotely from his attack device. Scripts are an ideal download source since their existence on the target device would not arouse suspicion. This videoed "attack" shows the following activities: 1. The ransomware and its dropper, the spyware program Eset clearly detects as shown in the video via Virus Total, was downloaded on the tester's device where Eset was not installed. 2. The password protected archive was extracted on the tester's device hard drive. 3. The tester starts up Win 7 in a VM on his device. The VM has Eset Endpoint installed and operational. 4. Within the VM, the tester using Win Explorer starts the previously downloaded Spyware dropper resident on the non-virtualized hard drive. I will stop at this point. This is not a legitimate remote execution attack scenario. -EDIT- I forgot to mention this. As far as that child process svchost.exe child process running in the video, it is not the system process svchost.exe located in the Windows System32 directory. That can only run under SCM control. If one has doubts, open up an admin command prompt window and enter svchost.exe. It appears it is successfully executed but no new svchost.exe process is created. That is because the request just silently errors out. So I have no clue what the process actually is other than it was created with protections preventing its termination; at least in a VM. Other than the protected process bit, this method; among others, may have been employed: https://security.stackexchange.com/questions/30985/create-a-unterminable-process-in-windows
  5. Below is a screen shot of Eset default firewall rule for inbound IPv4 ICMP including echo reply: Assuming you want to block inbound IPv4 ICMP echo reply, you need to create a similar rule specifying only ICMP Type/code of "0" less the quote marks. Set the Name field to "Block incoming ICMP echo reply communication." Set Action field to Block. Set Protocol field to ICMP. Set Logging severity to "Warning" if you want the event to be logged. Checkmark the "Notify user" field if you want to alerted to block activity occurring. Click on the OK button to create your rule. Your rule will now be positioned at the bottom of all prior existing rules. You now must position the rule using the arrow keys provided to immediately proceeding the existing default incoming ICMP rule. Click on the OK tab and any subsequent shown one to save your changes. Finally, reenter the Firewall rules editor and validate your rule is positioned correctly. Note: Eset processes firewall rules in top-to-bottom order. Your created block inbound ICMP echo reply rule will always be executed prior to the existing allow one.
  6. I must say, this is the best example of Eset's ransomware detection to date I have seen. AMS detected the injected ransomware code in the svchost.exe child process and neutered it. Since AMS is post execution detection and as the video clearly shows, some files had been encrypted. Eset did attempt to stop the ransomware execution. It did terminate the parent ransomware process and attempted to terminate the child svchost.exe process. My best guess to why it couldn't terminate svchost.exe is it was started as a protected process with such status that only the OS kernel could do so. One example of how this can be done: https://www.reddit.com/r/techsupport/comments/28s5rh/killing_an_unkillable_process/ The svchost.exe process then continued execution deleting the shadow volume copies of the encrypted files preventing any recovery of those using the shadow volume recovery processing. What this example does show is an issue I have been "harping about" for some time. This is reputational analysis by Eset. Here we have an unknown process spawning a child svchost.exe process. This is clearly suspect activity since svchost.exe does not normally start this way. A suspicious activity alert should have been generated at svchost.exe startup time. I would have to review the details of this one.
  7. Pretty sure this is the bugger: https://www.virusradar.com/en/Win32_Tinukebot.B/description since its using dllhost.exe: And again, starts from:
  8. As far as the TinukeBot trojan, Symantec has a write up on it dating to 2017. It is a backdoor and probably what is establishing the remote C&C connection. That variant was run via: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\"" = "%AppData%\[RANDOM NUMBERS FOLDER NAME]\[RANDOM NUMBERS FILE NAME].exe" So it might be worth a look at the registry run keys; especially the HKEY_CURRENT_USER ones.
  9. It appears that Newegg.com is shipping a "boxed" version of Eset. The license key is contained within the box on a printed page. You can install EIS in trial version mode now. When you receive the boxed version of Eset, you can then upgrade Eset to a fully paid version by just entering the license key you received. You do so by opening the Eset GUI and proceeding to the "Help and Support" section. Click on the "Change License" button. Click on the "Use a purchased License Key" option and enter your license key contained within the Eset box you received from Newegg.com.
  10. Here's another clever phishing e-mail password attack currently circulating: https://www.bleepingcomputer.com/news/security/voicemail-phishing-campaign-tricks-you-into-verifying-password/
  11. @Marcos since this activity appears to be COM based, check the logs for any WMI consumer or command event existence/activity.
  12. That isn't necessary. However, you might want to create exceptions in both software's for the other to minimize the risk of any conflicts.
  13. I got a bit "carried away" in my previous posting. Windows is such a "piece of garbage" security-wise, I can't control myself when thinking about the issue. The odds of a stand-alone keylogger being dropped on a device these days is about nill. Keyloggers these days are packaged in financial based malware along with a whole bunch of other nasty such credential stealing stuff and the like. Eset has always performed exceptionally well in AV lab tests against financial malware; in almost all tests over time scoring 100% detection. Emotet is a nasty bugger that Eset has one of the best detection rates against: https://www.us-cert.gov/ncas/alerts/TA18-201A Note above how passwords are stolen by Emotet. Not by a keylogger, but by misuse of legit password recovery tools. Also Emotet's primary deployment method is via phishing e-mail. Likewise, much less sophisticated phishing e-mails attacks are also very successful. Like the one from supposedly your e-mail provider that looks for all intent and purpose as legit. It usually states your password has been compromised and you need to change it with a link provided to supposedly your e-mail provider logon-on page. You click on it and arrive at a web page that appears to be your e-mail provider logon page. Well, it isn't and you enter your old password and new password. Attacker subsequently logs on to your e-mail account and does change the password to the value you previously entered. You've just been pwned and are completely clueless to how it happened. Oh, about that confirmation e-mail you should receive about the password change. Attacker will make sure its deleted upon arrival. Tip - almost all browsers have a setting that allows for storing of user names and passwords. Make sure that setting is disabled. Likewise, make sure your e-mail client is not configured to save your e-mail server connection password.
  14. Issue also exists on the Eset retail products. Here's the thread on that: https://forum.eset.com/topic/17991-as-soon-as-possible-option-of-scheduler/?
  15. It will help in regards to outbound firewall rules but won't cover all instances. Win 10 has system level apps that are like updated on a frequent basis. Eset has advanced memory scanning protection which is effective as long as the code signature is known. You can create HIPS rules for browser processes to prevent any process modification activities. Of course, you will need to create corresponding allow rules for legit processes that do like activities; e.g. explorer.exe, runtimebroker.exe, etc.. -EDIT- Also the previous method is not "bullet proof." Malware could inject the parent process and hook a thread into the child process. So now we need to protect the parent process, and its parent process, ad infinitum …… So view process protection as best guess effort. Yes.
  16. It is also possible what Eset is detecting is the vulnerable Java version/s. Is Java fully patched and up to data?
  17. Questionable. The attacker could inject the browser with a keylogger for example. @TomFace suggestion of using a password manager is a good one and should definitely be considered. You could also explore using a standalone e-mail client since these are less targeted by keyloggers. The main issue is if an attacker can install a global keylogger on your device. With this he can capture keystrokes from any app. Eset has improved its detection against these. It recently detected a .Net based one I created some time ago for testing purposes. It appears it is monitor for select API usage common to global keylogging and if detected, the process is uploaded via LiveGrid for inspection and eventual signature creation. So yes, interactive firewall monitoring of outbound traffic could detect a data upload. However, this is easier said than done. Also, the same issue with Win 10 store apps manifests in firewall rules since again, their process names are constantly changing. An "eye opener" is a review of the Win firewall log. What Win 10 does is dynamically delete old store app Win firewall rules and create new ones every time a Win 10 app is updated to a new name(version). Adobe Reader updater is also another app that performs like activity.
  18. I did a bit of research yesterday in dllhost.exe usage. It is associated with COM processing. Malicious browser extensions will employ COM. So I would be suspect of any recent Chrome extensions installed or the like.
  19. 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.
  20. I am wondering if Eset is detecting an old unused Apache app on the server? https://arstechnica.com/information-technology/2017/03/in-the-wild-exploits-ramp-up-against-high-impact-sites-using-apache-struts/
  21. 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
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...