djacobson

Here are some excerpts from some previous answers to this question.

I believe it is going to be included in an update currently targeted for 1/31.

Network drives are not scanned by the end-user workstation with the MBEP software, they are also no longer available to be scanned via the context menu option. This is something MBAM 1.x was able to do and if you are familiar with that older option, you may notice that MBEP's context menu option goes grey when attempting to right click network drives and engage the option. Drives like these should be scanned using an MB install on the hosting server where the drives are local and can be scanned as normal. As far as ransomware, if a workstation is hit it wouldn't matter what drive the ransomware is encrypting, or if that location happened to be ignored. We are looking at the malware's behavior itself, things like this are not running from your drive share in the QB folders, they are running in memory to attack the file system. The exclusions relieve whichever particular real-time engines that the exclusions can be, or are, applied to within the extra "Exclusion applied To" option set. The exclusions are for MBEP to ignore the excluded items, and what they are doing, not what is happening to them via something else. The main consequence and concern around what's been brought up in the previous paragraphs, is to be aware that an attack on an unprotected workstation can reach anything to which that workstation has access. Say there's an unprotected workstation, and it got ransomware and began to encrypt the system. When the attack is finished with the local drives and moves on to the network drives/shares, even if the server hosting the share has MBEP installed, the share is in danger in this scenario. The attack is in the unprotected workstation's memory, and the protected server's MBEP real-time cannot see that. It is vital to protect your servers by protecting all your workstations.

Hi @RickyF, give the service pipe registry key a try and policy startup delays, other than that, we'll need to wait for the upcoming release.

@j_french How is your policy setup? Where are the clients set get their signature updates?

Google's policy towards 3rd party protection will have to change before that can happen. The best approach for now is to leverage your scanner schedules as you have been doing, and malicious connections to internet addresses will be blocked by the web portion. Chrome removed from Anti-Exploit list of Protected Apps in Malwarebytes https://support.malwarebytes.com/docs/DOC-2655 The Google Chrome team announced in a blog post dated November 2017, it will not allow 3rd-party vendors to inject into the Chrome browser for Windows beginning in September 2018. Refer to Reducing Chrome crashes caused by third-party software for details - https://blog.chromium.org/2017/11/reducing-chrome-crashes-caused-by-third.html - "In September 2018, Chrome 69 will begin blocking third-party software from injecting into Chrome processes." Google believes this approach makes Chrome more secure and less prone to crashes, which they identify as the main source of stability issues with their browser. Security solutions such as Malwarebytes for Windows' Anti-Exploit functionality uses this injection into Chrome to provide an additional filter. The filter checks to see if the web pages rendered contain exploits and blocks it accordingly. In response to Google's decision, and to minimize the inconvenience to users seeing these incompatibility messages from Chrome, Malwarebytes has removed Chrome from the Anti-Exploit list of protected apps in the following products: Malwarebytes for Windows – Component Package version: 1.0.441 and above Malwarebytes Endpoint Protection Malwarebytes Endpoint Security While we find a way to restore protection for Google Chrome, Malwarebytes believes our other layers of protection such as web blocking, malware blocking, anomaly detection, anti-ransomware, plus the other protection applications in anti-exploit will continue to protect users from malware and other forms of threats.

The default policy is set to use the Incident Response product in a scan only config, have you changed it to run any realtime options? Just want to make sure there. Give an in-policy startup delay a try as well, upping the timer as you go, if you get to 120 seconds and it doesn't reliably start, then we'll need to look at something else conflicting with the service's attempt to be started. I do not recommend having the self-protect or self-protect early start on unless you are actively dealing with an infection that is targeting and modifying Malwarebytes' files. That is what the option is for, getting Malwarebytes to run on a heavily infected machine in which the malware is preventing Malwarebytes from running. In the past this feature was called "Chameleon" and was a free standalone tool. When MB3 came out, this product was turned into a feature within the main program. The B2B Admin Guide doesn't really discuss its usage. The B2C help guide has much more detail on the MB3 engine, this is what Cloud uses: https://www.malwarebytes.com/support/guides/mb/Settings2.html Enable self-protection module: This setting controls whether Malwarebytes creates a safe zone to prevent malicious manipulation of the program and its components. Checking this box introduces a one-time delay as the self-protection module is enabled. While not a negative, the delay may be considered undesirable by some users. When unchecked, the "early start" option which follows is disabled. Enable self-protection module early start: When self-protection is enabled, you may choose to enable or disable this option. When enabled, the self-protection module will become enabled earlier in the computer's boot process, essentially changing the order of services and drivers associated with your computer's startup. Not only does it introduce more delay to the startup, it also changes items to a read-only mode, which can prevent even the legitimate file changes Malwarebytes needs to do when upgrading portions of the program. Azure AD is an interesting angle, the support team will need a fair amount of information/logs from those machines, it would be best to open a ticket in regards to this lead.

Has the machine rebooted to take up the new service timeout config? Do you have an existing startup delay set in your policy?

See this post -

Hi @Buddy, this one is a new issue, but with a similar symptom as your past problem. For this one, pick out one machine and add this line to the registry via CMD or PS. Let me know if that works for you. reg add HKLM\SYSTEM\CurrentControlSet\Control /v ServicesPipeTimeout /t REG_DWORD /d 60000

That is a hurdle, I'm sorry it is not easier at the moment 😔

Hi @PTechS, if QB has a list of folder areas or network addresses used for the update, these locations can be added to Malwarebytes' exclusions area to help.

Hi @AlexLeadingEdge, that would be a nifty thing to add for the admins that like to research. I'll help get that submitted. Here's where you can find that info until it becomes a feature: In Quarantine, click on the detected threat and look for the Detection ID, this is the hash of the quarantine file. In this example, my Detection ID is 7a06df44-1524-11e9-bf13-00ff70609f10, so there should be a 7a06df44-1524-11e9-bf13-00ff70609f10.quar and 7a06df44-1524-11e9-bf13-00ff70609f10.data file in C:\ProgramData\Malwarebytes\MBAMService\Quarantine on the endpoint. On the endpoint, go to C:\ProgramData\Malwarebytes\MBAMService\ScanResults, look in the hashed *.json file with the same-ish timestamp as your scan, open the json in a text editor, confirm you have the right scan file to quarantine files by finding this line: [ID of the scan result json] { "applicationVersion" : "3.6.1.2716", "clientID" : "Endpoint Agent:[clientID]", "clientType" : "agentScan", "componentsUpdatePackageVersion" : "1.0.478", "cpu" : "x64", "dbSDKUpdatePackageVersion" : "1.0.8718", "detectionDateTime" : "2019-01-10T22:09:55Z", "fileSystem" : "NTFS", "id" : "760fa592-1524-11e9-9f28-00ff70609f10", A little later in the scan result json you can find the ID again, along with the MD5 and SHA256 of the detected and quarantined file(s). "threats" : [ { "linkedTraces" : [ ], "mainTrace" : { "cleanAction" : "quarantine", "cleanContext" : { }, "cleanResult" : "successful", "cleanResultErrorCode" : 0, "cleanTime" : "2019-01-10T22:10:46Z", "generatedByPostCleanupAction" : false, "id" : "7a06df44-1524-11e9-bf13-00ff70609f10", "linkType" : "none", "objectMD5" : "3B9269B0C31CA2CCFB30D75A83B0609E", "objectPath" : "C:\\USERS\\DJACOBSON\\DESKTOP\\TEST-TROJAN.EXE", "objectSha256" : "FC0771A47FFF3909627D224119BC4C9AD3CF8F11EA33CD7CE61A9B8894F5C23C", "objectType" : "file",

No problem! I'm glad I could help a bit, hopefully that gives more confidence in how MB works in these kinds of scenarios.

Hi @REGITDept. The extension is likely not doing anything to generate malicious behavior, and so only shows when the user's machine is scanned versus being picked up by the realtime engines. The process of installation itself is not malicious. We're not watching what you install, it's more like how it installs. Unless it is a situation where there is a dropper attempting to execute something other than what the user or allowed application had intended within the installer, there shouldn't be any provocation of the realtime to trigger. Chrome's user profile, bookmark and extension syncing process is not malicious on its own, it would not trigger our realtime under this normal syncing behavior, no matter what it happens to be pulling from your user's home machine(s) and installing to their workstation. But the moment whatever was installed runs, and attempts to maliciously hook in memory or run payload, that is when Malwarebytes' realtime engines will engage. An extra tip here is that malicious browser extensions tend to be items which attempt to poison or doctor search results and land you on a bad link (most just serve up ads though), if that link or ad has a malicious server on the other end, the connection will be dropped as Malwarebytes' web blocker engine would engage. This is a typical case as many of the programmatic functions of extensions aren't doing anything malicious enough to trigger the file, exploit or ransomware engines. The web portion is the likely the block you'll see until a scan cleans out the items. More options around this for consideration; disabling Chrome's autosync ability via GPO, sparing your environment the stuff on your user's home machines. Google's team has posted how to do this in Chrome support thread. Another one may be leveraging Windows Applocker, which can provide an extra dimension of control over what ends up on machines where users may have perms enough to install software. This is especially useful if you have exec's that insist on "being admins" on their machines, but regularly get themselves in trouble with the crap they install on their computer.