itman
-
Posts
12,197 -
Joined
-
Last visited
-
Days Won
321
Posts posted by itman
-
-
22 hours ago, red pill said:
the cleanmgr also want to start applications in that directory, is this normal?, should I create a similar rule about starting application from this directory?
Correct. Forgot to mention that. For example, it starts DISMhost.exe.
-
1 minute ago, Moneesh said:
A cmd window opens for half a second and nothing else happens.
Again ….….. Right click on the downloaded file and run it as administrator.
-
6 hours ago, Moneesh said:
But i searched for Eset Vulnerability Checker and ran the application and i got this,
As posted above, here's the download link: ftp://ftp.nod.sk/samples/svchecker/ESETSysVulnCheck.exe
Right click on the downloaded file and run it as administrator. It will create a zipped file in your Downloads folder. Attach that to your reply.
After seeing you are still vulnerable to the EternalBlue exploit, I am "bowing out" from any further replies.
-
32 minutes ago, Marcos said:
3, "Basic mode ignores containers" - even potential malware in archives does not pose any risk since it would be detected by real-time protection upon extraction. The goal of the Smart scan is to scan local disks for threats as quick as possible and therefore it has scanning of archives disabled intentionally.
To this, I would add Eset scans archives upon download and prior to creation on the disk using its Web Filtering protection.
Two tests to verify its effectiveness in this regard are:
https://www.amtso.org/feature-settings-check-download-of-compressed-malware/
The Fortinet test is designed to test corp. Network perimeter security devices. Eset scored 17/18 which Fortinet rated excellent.
-
4 minutes ago, red pill said:
so in the HIPS rules i should make a rule with files enabled at the "operations affecting" section, then at the "source application" section adding "C:\Windows\System32\cleanmgr.exe", and then at the "file operations" section enabling "delete file" and "write to file", and then at the "files" section choosing specific file and then adding "C:\Users\ZX\AppData\Local\Temp\*" ? . the * in the "C:\Users\ZX\AppData\Local\Temp\*" will mean that the rule will affect any file at the C:\Users\ZX\AppData\Local\Temp\ directory?.
Yes.
-
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:
QuoteThe cybersecurity team from Fortinet recently captured a sample relating to the spread of NanoCore RAT in the form of a malicious Microsoft Word document.
[...]
Two processes will be running at this stage; Netprotocol.exe, which is a copy of CUVJN.exe and is the daemon designed to unzip NanoCore, alongside dll.exe, which is a very interesting daemon process in itself.
Dll.exe is designed to keep the Trojan running. The process starts netprotocol.exe, injects NanoCore into memory, and runs the code. One of the process' classes is called "ProtectMe" with a function "ProtectMe.Protect()" which prevents the process from being killed off by the victim. During testing, Fortinet researchers could not kill the netprotocol.exe process at all -- despite it not being a system service or containing higher privileges than the user.
It turns out that the process uses a function called ZwSetInformationProcess, from NTDLL.dll, is able to modify the state of the process and prevent it from being disabled."There is a function named "RunPE.doIt()" that is used to run and protect the NanoCore RAT client. It calls the API CreateProcessA to start a new "netprotocol.exe" and then suspends it," the researchers say. "Next, it allocates memory in the new "netprotocol.exe" and puts the entire NanoCore into the newly allocated memory using the API WriteProcessMemory. Finally, it modifies the entry point of the thread context to NanoCore's entry point and resumes NanoCore running inside the second "netprotocol.exe" by calling the API ResumeThread."
Ref.: https://www.zdnet.com/article/nanocore-trojan-stops-you-killing-its-process/
-
8 hours ago, Marcos said:
By default echo to ping from outside trusted zones should be blocked. Please check if you have trusted zones configured properly.
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. -
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.
-
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:
QuoteA defence against this is to create a dummy process that spawns the keep-alive process, then have that dummy process exit. The main process passes its ID to the dummy process, and the dummy process passes its ID to the keep-alive process, but the chain is broken when the dummy process exits. This leaves both the primary and keep-alive processes running, but makes it impossible to use Task Manager's kill process tree function. Instead, you'd have to write a script to kill them off, or use a tool that allows you to kill multiple processes simultaneously.
https://security.stackexchange.com/questions/30985/create-a-unterminable-process-in-windows
-
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.
-
4 hours ago, sdnian said:
And my problem is: this example, ESET has not been destroyed, the malware is already detectable, and ESET has detected it after execution. Why keep it working? Why can't ESET terminate it?
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:
QuoteYou can try using
psexec -accepteula -d -e -i -h -s cmd.exeto launch a Command Prompt as theNT AUTHORITY\SYSTEMuser, giving you kernel-level privileges on the local machine.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.
4 hours ago, sdnian said:The ransomware virus executed by Powershell, ESET is still only detected, and can not terminate its encrypted file.
I would have to review the details of this one.
-
Pretty sure this is the bugger: https://www.virusradar.com/en/Win32_Tinukebot.B/description since its using dllhost.exe:
QuoteThe trojan creates and runs a new thread with its own program code within the following processes:
%system%\dllhost.exe
And again, starts from:
QuoteIn order to be executed on every system start, the trojan sets the following Registry entry:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"%variable1%" = "%appdata%\%variable1%\%variable1%.exe"
-
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 hours ago, Moneesh said:
i have created a firewall rule to block anything inbound/outbound related to the IP address 51.15.90.178.
Did that stop the Eset alerts you were receiving?
-
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.
-
Here's another clever phishing e-mail password attack currently circulating:
QuoteEdgeWave has confirmed BleepingComputer's suspicion that this is being done to double-verify the password and that it is not currently a common practice. Phishing expert NullCookies also told BleepingComputer that only a "subset of kits do that".
NullCookies also stated that continuously "showing an incorrect password alert can also be used to avoid redirecting to the impersonated company’s website." This gives the phishing scam additional concealment.
-
@Marcos since this activity appears to be COM based, check the logs for any WMI consumer or command event existence/activity.
-
2 minutes ago, jems said:
And if so, should i disable EIS when i run MWB?
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.
-
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:
QuoteWebBrowserPassView is a password recovery tool that captures passwords stored by Internet Explorer, Mozilla Firefox, Google Chrome, Safari, and Opera and passes them to the credential enumerator module.
Mail PassView is a password recovery tool that reveals passwords and account details for various email clients such as Microsoft Outlook, Windows Mail, Mozilla Thunderbird, Hotmail, Yahoo! Mail, and Gmail and passes them to the credential enumerator module.
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.
-
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/?
-
50 minutes ago, red pill said:
It will help if I simply disable windows 10 app store and adobe reader updater?
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.
50 minutes ago, red pill said:ESET can protect me from attacker that try to inject keylogger in my browsers? there is something I can do in the ESET configurations to increase my protection against it?.
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.
50 minutes ago, red pill said:It will work on my ESET smart security premium?
Yes.
-
It is also possible what Eset is detecting is the vulnerable Java version/s. Is Java fully patched and up to data?
-
12 hours ago, red pill said:
Is switching the firewall feature on ESET to "learning mode" and then to "interactive mode" can help me at least stop potential spyware from sending information to the hacker?.
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.
-
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.
Frequently receiving notification of blocked website
in Malware Finding and Cleaning
Posted · Edited by itman
Possible but doubtful. I suspect the attacker switched to a URL not currently blacklisted by Eset.
Modify the firewall rule you created to block inbound and outbound activity for C:\Windows\SysWOW64\dllhost.exe instead of the previous IP address. As far as I am aware of, this process should never perform any Internet activity. Assuming you are using the Win firewall, check its firewall log for blocked dllhost.exe connections.