McAfee Web Control & Outlook Email Annotations


This post explains the investigation steps we took and the tools we used to work out how McAfee Web Control functions within our IT Estate.

Topic on McAfee Forums:

Problem / Issue we have with McAfee Web Control

Email annotations do not load on malicious sites that appear in emails in Microsoft Outlook.

How does McAfee Web Control Work?

Web Control uses JavaScript as its core to display the Web Control warning, So Web Control uses executable mfewc.exe to do all the work.


It also calls a child process which can be seen.

Outlook references the DLL files which can be found in the Web Control installation directory (C:\Program Files (x86)\McAfee\Endpoint Security\Web Control) like wchook.dll.

There are two versions of the wchook.dll which are 32bit and 64bit. This has no effect on the Microsoft Office version, just the Windows Operating system architecture. 

  • C:\Program Files (x86)\McAfee\Endpoint Security\Web Control\x64\wchook.dll
  • C:\Program Files (x86)\McAfee\Endpoint Security\Web Control\wchook.dll

I used a tool to check the DLL type to confirm this, as you can see the wchook.dll which I believe is used to hook into the Outlook.exe process, does support both 32 & 64bit Windows.

c:\program files (x86)\mcafee\endpoint security\web control\x64\wchook.dll:

Verified:       Signed

Signing date:   10:54 28/11/2018

Publisher:      McAfee, Inc.

Company:        McAfee, LLC.

Description:    Web Control

Product:        Web Control

Prod version:

File version:

MachineType:    64-bit

C:\Users\newmant>sigcheck “C:\Program Files (x86)\McAfee\Endpoint Security\Web Control\wchook.dll”

c:\program files (x86)\mcafee\endpoint security\web control\wchook.dll:

Verified:       Signed

Signing date:   10:50 28/11/2018

Publisher:      McAfee, Inc.

Company:        McAfee, LLC.

Description:    Web Control

Product:        Web Control

Prod version:

File version:

MachineType:    32-bit

NOTE: McAfee Web Control only works with 32bit versions of Outlook.

Monitoring the behaviour of Web Control shows the Web Control Service in a “Wait” sate, waiting for “mfewc.exe” to pickup any malicious URLS.

“C:\Program Files (x86)\McAfee\Endpoint Security\Web Control\mfewch.exe” saHooker_Initialize_and_Wait 

When Web Control is running on a working 32bit version of Outlook, you will see Outlook loads the McAfee Web Control DLL file for use.

outlook.exe pid: 6504

Command line: “C:\Program Files\Microsoft Office 15\root\office15\OUTLOOK.EXE” 

0x0000000070510000  0x1e000    C:\Program Files (x86)\McAfee\Endpoint Security\Web Control\wcHook.dll


How does Web Control make email annotations to emails like the ones below? Outlook doesn’t have a plugin for this, it’s all controlled with JavaScript.

So there are quite a few Javascript .js files that do the work of displaying the warning in Outlook, the main one is this JS file.

 C:\Program Files (x86)\McAfee\Endpoint Security\Web Control\scripts\safe_im.js 

 Location of scripts

C:\Program Files (x86)\McAfee\Endpoint Security\Web Control\scripts

You can see if references various applications it can display the warning for, which Outlook is a part of.

Also I found this for McAfee Site Adviser which was the previous product before Web Control that did this, that “Message Preview” is required.

Network Level Troubleshooting

Where does Web Control obtain its ratings, is it from the ePO Server? Ratings do not come from the ePO server. Ratings come from on port 443.

When corrections are made to the Web Control scripts, the Web Control client automatically downloads them from

The URL McAfee looks up is below, it tags the malicious URL at the end and looks it up.


Looking at the logs and using Wireshark I was able to find the websites Web Control was using, and these interesting error messages about HTTP 403 return codes, which basically mean Web Control is unable to get to these sites.

McAfee Log:  C:\ProgramData\McAfee\Endpoint Security\Logs\WebControl_Debug.log

Line 74275: 09/20/2019 11:08:07.056 AM    mfewc(6344.7384) <SYSTEM> WebControl.SaSSHMod.Debug: Http request for url [] is forbidden (HTTP_STATUS_FORBIDDEN/403)

Line 74274: 09/20/2019 11:08:07.056 AM    mfewc(6344.7384) <SYSTEM> WebControl.SaSSHMod.Debug: Http status code returned = 403 

09/23/2019 12:06:38.472 AM    mfewc(2612.3016) <SYSTEM> WebControl.SaSSHMod.Debug: Http request for url [] is forbidden (HTTP_STATUS_FORBIDDEN/403)

What was the solution?

I added the following exclusions to the “Semi Restricted Whitelist” and the “CFS URL” list in our SonicWall Firewall.  I’m not sure if all these sites are needed such as “” but when running a packet capture on the client and firewall on a device with a malicious email open I could see this traffic being dropped, that’s why I whitelisted it.

A reboot is required before Web Control kicks in.

  1. (It’s a CDN, so probably used to speed up web control:
  2. *

To confirm this was the cause I used “Microsoft Network Monitor” on a working machine, which is a tool that shows you process level network traffic, and you can see that the process “mfewc.exe” McAfee Web Control is communicating on port 443 with McAfee servers.

Testing & Confirming the solution

So as we know Web Control only works on 32bit versions of Outlook, after testing this on a few machines after rebooting them, I was able to get the warning message by using the test site

You can see this being flagged in Outlook and Internet Explorer.

If you look in the log, when McAfee Web Control has found the URL as malicious, it will log it here.


Log to look for

C:\ProgramData\McAfee\Endpoint Security\Logs\WebControl_Debug.log

vSphere Client could not connect to IP (The operation has timed out)

We had an issue today where we were unable to logon 
to a ESX host via the vSphere Client.

These were the sort of error messages I was getting.

I spent a lot of time on Google, which lead me to many
different knowledge base articles, which were 
not related to the issue I was having.

Most were relating to file locks on the database on the
ESX host, but the errors didn’t tie up with the logs on the ESX host.

I ran Wireshark, and could see it had established a
TCP three way handshake, but started to drop packets
when trying to communicate over port 443.

I found online the log that contains information for the sign on process is 
located here: /var/log/vmware/vpxd/vpxd.log

I checked in the log and found that port 443 was already in use.

 2018-03-20T15:06:37.661Z [7F4321A15740 error ‘vpxdvpxdMoReverseProxy’] [VpxdReverseProxy] Failed to create https proxy: Resource is already in use: <acceptor p:0x00007f4308117200, h:33, >

2018-03-20T15:06:37.661Z [7F4321A15740 error ‘vpxdvpxdMain’] [Init] Init failed: ReverseProxyMo::Init()

I checked for open ports to work out what process was using port 443, and found it was using the process ID of 5911.

netstat -plnt | grep ‘:443’

tcp      129      0   *               LISTEN      5911/vpxdtcp                           4       0 :::443                  :::*                               LISTEN      5911/vpxd

I then searched for the PID to find the name of this process.

 ps -A | grep 5911

5911 ?        00:00:00 vpxd-worker

I stopped the parent process vmware-vpxd, which should stop the child process vpxd-worker but it didn’t.

service vmware-vpxd stop

I searched again for open ports, and even though the parent process vmware-vpxd had stopped, the port 443 was still in use.

The vpxd-worker process manages crash dumps. I killed off the process using the kill command.

kill -s KILL 5911

I then started the service, and it managed to successfully start.

service vmware-vpxd start

Tired of Windows updates – Defer Updates in Windows 10

Windows 10 has a feature to defer updates for several months, while still receiving critical security updates.

This is ideal for those who want to make sure updates are thoroughly tested before you install them on your beloved computer.

1. Go to Settings (keyboard shortcut: Windows key + I) > Update & security

2. Tap or click Advanced options

3. Check the box, Defer upgrades