djacobson

A few features that were slated for Nov. 15th had been pulled due to showstoppers. Those were fixed and sent out on Nov. 27th to finish the release update. There was a change included with the Incident Response for Windows, where a scan dialogue window was incorporated. If the user initiates the scan, they can cancel it. This is popping up on your server because one of your users started a scan. Remove the software from your Citrix server or disable the incompatible roles. Citrix and Terminal server's can only use the Exploit protection feature, create a new group and policy for these servers and keep the Web and Malware pieces disabled as they do not support the role, and the Ransom protection should also be disabled as it does not support server OS.

Console slowness, 504 errors and offline agents - 12.1.17 - fixed Issue identified, event caused by sudden increase in traffic for agent results, many times more than the standard traffic. Situation has normalized and consoles should start becoming accessible again, clients which dropped offline during this event should start coming back online as of 1pm PST.

Anti-Ransomware is included for Endpoint Security subscriptions, however in that product, it is a standalone tool and not manageable or deployable through the Management Console. Anti-Ransomware is also for client OS, win 7 and up only. Server's are not supported by it at this time.

MBMC on a desktop OS is not supported. A secondary console can be used on desktop OS but the main server portion must be on a server.

The Malwarebytes Management Console does not provide any protection, it is merely an application to manage the protection software deployments and configuration on other computers. If you wish to protect your servers, you can deploy to them as well but understand that some server roles are not supported even when the OS is.

Console slowness, 504 errors and offline agents - 12.1.17 Amazon AWS Retina API running near 100% memory utilization. Cloud admins may experience slowness, inability to load console, offline agent condition likely as well. Issue is under investigation.

Is this for a secondary console or the whole console server install is on a Win 10 desktop?

Found means a detection was found but no action took place - this happens when you use scan and report on-demand scan, and for scheduled scans if you do not have the quarantine threats automatically option turned on in the schedule entry. Quarantined means a detection was found by the realtime or the scanner and the object was quarantined. Blocked means the web blocker blocked a connection attempt to a known malicious IP.

That is a Group Policy Object modification to force Windows 10 machines to open "This PC" instead of "Quick Access", add it to your exclusions like this... HKU\*\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXPLORER\ADVANCED|START_SHOWMYCOMPUTER

There's no real elegant way to do it, that XML is only imparted to the clients during a push, there's no interaction with it on the clients once that is over. The cleanest way I can think of, is once the console is set with the address you need to access it via the console, go to the package template area and edit the source sccomm.xml that the server copies for pushes and package generation - C:\Program Files (x86)\Malwarebytes Management Server\PackageTemplate\sccomm.xml. After this, a package generated or new push deploy will have that address within it from the start. Be aware, any time you make a change to the servers address, this source file gets changed too, you will need to redo the public address in the package template area if any new connection address changes happen. Any computers already installed can have their sccomm changed out while the service is off. A GPO run once reg entry assist is a good way of doing that. Copy the corrected sccomm.xml and a text.bat script to the C$ share. The script should tell the meecleintservice to stop, copy the new sccomm.xml file from your behind the scenes copy to the correct location, then restart the service. Call on that script via the GPO run once reg, that'll hit everyone without repeating on subsequent log ins.

I circled back with him, I should have some feedback soon!

Hi @ciliegia, I apologize for the time, I goofed up and lost track of your post. Your install is out of date, but the signature revision is fine, this is why it is saying database is already up to date. Malwarebytes Anti-Exploit version 1.11.1.18 (HKLM\...\Malwarebytes Anti-Exploit_is1) (Version: 1.11.1.18 - Malwarebytes) Malwarebytes' Managed Client (HKLM-x32\...\{72BE25D7-574A-4F4D-B9B3-907D239CE1C7}) (Version: 1.7.0.3208 - Malwarebytes) The latest package is available here - https://downloads.malwarebytes.org/file/mbes_for_business Upgrade instructions are here - https://support.malwarebytes.com/docs/DOC-1043

Hi @JoesCat, each of your user accounts has a double start entry. There is a concerning GUID which is indicative of infection behavior. These are your two entries, the normal one is on top the concerning own is below, all user accounts that I could see have this... HKU\S-1-5-21-128000122-1685152614-964376902-1267\...\Run: [Endpoint Agent Tray] => C:\Program Files\Malwarebytes Endpoint Agent\UserAgent\Endpoint Agent Tray.exe [546248 2017-11-28] (Malwarebytes) HKU\S-1-5-21-128000122-1685152614-964376902-1267-{ED1FC765-E35E-4C3D-BF15-2C2B11260CE4}-11282017005408544\...\Run: [Endpoint Agent Tray] => C:\Program Files\Malwarebytes Endpoint Agent\UserAgent\Endpoint Agent Tray.exe [546248 2017-11-28] (Malwarebytes) Download your Malwarebytes Breach Remediation tool from your Cloud portal in Endpoints \ Add \ Malwarebytes Breach Remediation. You'll need your key that is part of your subscription in order to activate, update and scan with this tool, it can be found on your MyAccount portal, let me know if you need that. Place the MBBR.exe somewhere, the desktop is convenient. Open and admin elevated CMD prompt and CD to MBBR.exe's location. Use the following commands: mbbr register -key:[paste your key here] mbbr update mbbr scan -full -ark -remove -noreboot Upload you scan log results, it'll be in the same directory that MBBR runs from.

The console can only have one address assigned and it is specifically looking for localhost / AD FQDN or internal IP for the server. This is one thing you may find with the MBMC console; there are many aspects of it that are hardcoded, like names and timeouts. Check out your server's config file in C:\Program Files (x86)\Malwarebytes Management Server\SC.Server.WindowsService.exe.Config, you may get some ideas after checking that out. The clients can all be manipulated to resolve to public through their XML, do it for your local ones as well instead of splitting private/public between locations. You may have to just live with the management side's problem when RDP'ing into the server and using the main console or from your workstation when using a secondary console. Even if it connects on localhost or 127 loop for local, or external IP for secondary, you'll always have that message because those addresses do not "match" to what the console has assigned to it via that config file.

The console server's configuration requires the address to be the IP or FQDN, those are the only things it can use. Straying from this will present you the error you see even if it can log in to the console. To get the clients to connect, you may have some success manually changing the server connection string in their config xml, C:\programdata\sccomm\sccomm.xml, this is where folks that have done MSDA have had their success. To be clear though, this is not something we can support, it is done at your own risk. For full disclosure, I had gotten my own test environment to run MSDA long ago, how that is configured may help you or give you ideas. I ensured the server name in Server Configuration was not configured as an IP4 address, but as the FQDN. I then created a installation package for a manual install, this part isn't as important as any client can have their config changed after install. I then stopped the MEEClientService on the endpoint, then copied the sccomm.xml file to my desktop for editing, made the edits, placed the desktop copy back into the original location, letting it overwrite the existing original default one. Here's how a client's sccomm.xml file looks by default: <?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="ServerRef" value="https://[IP or FQDN]:18457/SCClientService/" /> <add key="Group" value="[Group GUID]" /> <add key="Client" value="[Client GUID]" /> <add key="Policy" value="[Policy GUID]" /> <add key="RegisterResult" value="Passed" /> </appSettings> </configuration> The configuration on my Direct Access (DA) client now looks at: <add key="ServerRef" value="https://[FQDN]:[PORT]/scclientservice/<https://3e:[PORT]/scclientservice/>" /> The Direct Access client was able to resolve this change in the XML and now my remote DA client is managed via the console. For your path though, I think the best approach to get the name to resolve is to do it manually in your host files or in your DNS, the console itself is not going to accept it, you'll need to do the routing behind the scenes.

Offline Agents - 11.28.17 The Amazon AWS Super Queue Service utilized by MBEP is having long queue times, causing some clients to show as offline in the Malwarebytes cloud platform. The issue is temporary, machines will come back online as the AWS SQS service catches up. Quick info on how Amazon AWS SQS works - https://aws.amazon.com/blogs/aws/sqs_super_queue/

443, 135 and 137 are for outbound from the server to the client for the push installer tool, there's no need to expose them externally (at least for how the console was meant to be used). Remote administration and WMI should also be allowed. MBMC also uses netbios protocol for the push tool, so if you push outside of the MBMC server's subnet, you will not get a reply back from the clients without a WINS server in place to relay back the reply. All these pre-reqs can then be closed again once deployment is complete. This stuff is not applicable to you anymore when you use a third party deployment tool. I've included it for some clarity on what that tool needs to work, however 18457 still needs to be open for management after deployment, though this can be changed to a port of your choosing. It only needs to be outbound, upon connection the machines will perform a handshake and transfer whatever it is they need to, no need to risk inbound. The MBMC product does not support roaming or remote clients / console access. I have seen some customers use VPN, DMZ and Microsoft Direct Access to access it though we cannot really provide information on how to do it, this will need to rely on your own resources and abilities as an admin. For how you are setting this up though, I would recommend to not have the clients try and look to the MBMC server for their signature database updates, instead choose the update from internet option. This will also save you a ton of bandwidth as it allows for an incremental update instead of a full pull from the MBMC server. Incremental is 3-5kb from the internet in size versus 15-25mb each pull if from the console. Add these to your network software or appliance to be allowed external access, also allow these URL's to be bypassed by any deep packet inspection or SSL filtering. If you do not, the built-in MITM protections the program has in place will cause the program to drop all packets and you will not be able to connect to the needed pieces for the program to update and run correctly - External URLs to have open for MBMC Console and Clients https://data.service.malwarebytes.org https://data-cdn.mbamupdates.com <-must be accessible to process updates https://keystone.mwbsys.com All are port 443 outbound, also add the keystone address to IE's trusted site list and disable IE Enhanced Security if you still have it enabled on your MBMC server.

Are you trying to set MBMC up to be accessible from outside of your network or accessible from alternate domain forests?

@CHall I remember you mentioning it in the event viewer post. That's the Windows BFE service conflict. You are having those other symptoms still after choosing which web real time? Are there any mutual process exclusions in place between your MB and Controlnow? I imagine you may have gone over that in your ticket though, no?

The tool needs to be ran as administrator. Start CMD as admin and when you use the commands, it will have the permissions needed to remove everything.

I do not see any purchase, business or consumer, tied to the email used on their forum account. @paulabolen please let us know what product you are using.

Macs can only use the Incident Response product, Endpoint Protection is not supported for Macs right now. Macs need to be on their own group/policy and be set to Incident Response on, which will automatically disable Endpoint Protection as these pieces are mutually exclusive.

Hi @JoesCat, run this tool on one of the machines - Frst Log Please follow the steps below to run frst. 1.) Download frst and frst64 from the link below and save it to your desktop: FRST 32-bit version: https://downloads.malwarebytes.com/file/FRST FRST 64-bit version: https://downloads.malwarebytes.com/file/FRST64 Note: You need to download the version compatible with your system. If you are not sure which version applies to your system, download both of them and try to run them. Only one of them will run on your computer; that will be the right version. Some traditional Anti-Viruses may false positive the download or running frst, I can assure you it is safe. If this happens, please temporarily disable the AV. 2.) Double-click the purple frst or frst64 icon to run the program. Click Yes when the disclaimer appears. 3.) Click the Scan button 4.) When the scan has finished, it will make 2 log files in the same directory the tool is located, frst.txt and Addition.txt. Please attach frst.txt and Addition.txt in your reply.

Hi @Limon. No, the on-demand and scheduled threat scan does not look for rootkits natively unless you engage that option within the policy. Threat scan is equal to the old quick scan. Full scans can be setup via Custom scan option and engaging the "scan all local drives" piece in the scheduler. Despite there being a scan for rootkits (when threat scans run) in your policy, I would advise you to not do that as it can add a lot of additional time to each scan you send and it is not necessary to scan for rootkits all the time, only when you suspect or see rootkit behavior. I would suggest you utilize the custom scan option set in the scheduler to setup specific, rootkit only, scans instead of tagging on rootkit scanning to other scheduled and on-demand scans.

@IT_Guy and @TonyCummins, the first person that replied is not staff, they are a user just like you guys, with their own experiences and opinions, but they were correct in that the ANTI-MALWARE portion does not detect JS and other scripts. This is something we've been open about for the entire time Anti-Malware has been around. Script protection is the domain for the newer ANTI-EXPLOIT part of your protection, @Scolette, make sure all of your product pieces are fully engaged and operational for your applicable groups/policy, if you need assistance with that, that is certainly something we can help you check. @KDawg is correct in that the Anti-Exploit portion would have hit on this JS script if it had been invoked. Remember that Anti-Exploit doesn't scan, it is behavior based and needs to see the run and hooking attempt for its action to take place. A scan would be done via the Anti-Malware portion of the product, which cannot "see" that the JS is malicious before it is ran, due to what it is made to look for and how. I hope that makes sense. I can try to expand on that if needed. Also keep in mind that ADWCleaner is an aggressive browser hijack/ deep PUP remediation tool, a JS doesn't fall within its abilities, unless that JS infection also happened to add a ton of search "tools" to your browsers as part of its overall payload, it would pull those out of your browsers for sure. The MB3 and MBEP products are AV replacements, caveat being when all pieces are in place, not just MBAM or MBAE, etc, this is why MB3 and MBEP have all our products / technologies built into a single, multi-faceted program, instead of separate programs, like they are in the older MBES product versions. Now with that said, it is still a good practice to have an AV in place. And there is good reason to do that, more layers in the net to catch things! Plain and simple. If you need help getting the AV you've chosen to work with our products, we will always help you do that.