VMware Communities
Johansson90s
Contributor
Contributor

Malwareebytes insists vmware-hostd.exe, even after whitelisting the vmware-folder

-Website Data-

Category: Compromised

Domain:

IP Address: 176.96.238.149

Port: 443

Type: Inbound

File: C:\Program Files (x86)\VMware\VMware Workstation\vmware-hostd.exe

Reading through the docs I couldn't really find anything about it which made me mildly worried.

At the same time a program with a mission such as hostd is bound to raise eyebrows for antiviruses.

At the same time both companies are big, and often spoken about as best in their field, one would think it would be already sorted unless some shady code has been injected.

I don't know, but I'm not really keen on taking risk so I am blocking it until I get some clarification.

Reply
0 Kudos
5 Replies
Johansson90s
Contributor
Contributor

Seems they got through both malwarebytes and windows 10 firewall with all incoming blocked.

-Website Data-

Category: Compromised

Domain:

IP Address: 196.31.28.114

Port: 445

Type: Inbound

File: System

-Website Data-

Category: Compromised

Domain:

IP Address: 211.214.17.201

Port: 135

Type: Inbound

File: C:\Windows\System32\svchost.exe

Thank you for the website I have some hosts to contact.

Reply
0 Kudos
Johansson90s
Contributor
Contributor

So just an update for the records of the internet (unless someone has something to add)

I kept getting attacked from other host locations in India and Nigeria. Finally they got in but I believe after wasted hours I am now clean.

It is still unknown if they'll attack any service or the specifically begin with the vmware-related one, from research of open source programs of similar nature they escalate privilege up to system then hide, normally spying, stealing or installing cryptominers,

Thanks again for that one reply, amd as a final word, blocking all incoming traffic in windows firewall is a single click and 99% of the time you wont notice the difference at all. You could do it to a friend and they'd never ever notice.

-Website Data-

Category: Compromised

Domain:

IP Address: 196.31.28.114

Port: 445

Type: Inbound

File: System

-Website Data-

Category: Compromised

Domain:

IP Address: 211.214.17.201

Port: 135

Type: Inbound

File: C:\Windows\System32\svchost.exe

Who examples of migration to more critical systems.

[SUGGESTED READING] Official Malware Removal Guide : techsupport  useful recourse (kill.exe is a tiny 2 second download that actually works btw, it takes 10 seconds and gives you a small readable log on the desktop)

Stay safe out there, I still have to call these companies because 0/3 replies to e-mails.

Reply
0 Kudos
Johansson90s
Contributor
Contributor

On a second read the in a much less stressed mode, I am interpreting as you speculating that it was false alarm? I can assure you one of them eventually slipped passed a trojan.

Reply
0 Kudos
bluefirestorm
Champion
Champion

I would expect Malwarebytes or any other intrusion detection software to raise an alarm and/or block any unexpected/suspicious incoming IP traffic regardless of the source IP location/country. The other two alerts were on ports 445 and 135 which are normally associated with NetBIOS/RPC. Why would machines from varied geographies attempt such connections to where you are (where ever you might be)?

I don't think these are false alarms though but they did get blocked. The vmware-hostd.exe is the "VMware Workstation Server" in services.msc. It is used for the Shared VMs feature. If you don't use Shared VMs, you can disable/stop that service and still continue to regular VMs with Workstation Pro. I can't say what to do with the other two as one is System and the other is a generic svchost.exe.

Reply
0 Kudos
Johansson90s
Contributor
Contributor

Sweden, and thanks for the interesting info. I do not know much about vmware but I know a thing or two from the other side of things.

The way you describe vmware.hostd.exe would imply it is a typical risk-factor, but id need a lot of time studying vmware and scimming through virus repositories to know if it is being used that way. The very way you describe it would put  the likelyhood of the vmware team not knowing about this risk and creating ways to deal with it at 0.

It should also be known I uninstalled malwarebytes to sample various systems to counter this, and sadly you are not allowed to go offline while doing so in 9 times out of ten. It is thus possible windows defender did poorly and malwarbytes, if left alone, would have provided protection from every attempt. Because as you said, the examples I provided were all blocked, the others were destroyed angrily when I learned what wmware "support tool", which they refuse to help unless you run and send them the zip file, collects.

Anyway, I found a similar virus on github, a mere two weeks after windows defender had learned to deal with it, if it was anything nearly as strong it would mean complete reinstallation of windows to cure, and absolutely everything private on your computer in hands of crooks with the sole excepton of encrypted info that was not unencrypted during infection. To the best of my knowledge, system.tier privilege infections that can travel between services freely and act like a small part of a normal running windows service are nearly impossible to deal with. Luckily this is somewhat of a semi-test machine with encrypted clouds on stand-by, so no big risk was taken.

I Still find the situation incredibly curious, however, and of public interest.

I'll be back after math exam and studying both aforementioned subjects. The actual trojan detection is sadly gone due to malwarebytes insisting that I install an program that collected an atrocious amount of private info, zipped it, and then requested it sent to them to them. Or they flat out refused to help. Trojan detecting gold still goes to malwarebytes with windows own defender and firewall on extreme settings completely failing on this one. Second place to eset. Hall of shame to norton this time.Good bye for now.

Reply
0 Kudos