djacobson

@EthicalPrivate another idea was brought up by the D&D tool uses your DNS to resolve that address, this could also be an issue with the DNS cache. Try an IPCONFIG /flushdns to reset that and see if it can help.

Set anti-rootkit scans to be on a schedule on their own rather than engaging the setting to make them run with every scan you perform. Recognizing when to use that will come with experience in dealing with rootkits and knowing the signs of one being there. These scans are highly intensive and ideally should not be ran with other scanning functions, they can also at times crash your system, not just the application, due to the sensitive areas this function scans. This becomes even more sensitive if disk encryption is used. I think however, your true culprit may have been the SP early start. This is the old Chameleon function in an updated form. It sets MB stuff to be read only. Early start pushes that into the Windows loading process. Sometimes files need to change, even ours, we do update after all! This setting restricts this need and can have unintended consequences. I recommend this to only be used if you are dealing with malware that targets MB and nothing else - this was more common in the early 2010's, not so much anymore, but it could see a resurgence. Regular SP mode is fine to engage to prevent your users from deleting items.

This is a community utility and not an "official" product / tool. However, it could become one one day!

Please disable self-protection early start (you do not seem to be fighting an infection that targets MB) and turn off having anti-rootkit scan on for all scans. ARK scans are best done scheduled to run on their own.

I have not gotten a moment to go through them yet.

@kramdish my bad! Hold Crtl and then right click, you'll get the extra menu option for logs and debug.

I know for sure 2008 R2 64 bit is supported so far to our latest 3.7.1 - I have this setup in my test environment, unfortunately I do not have a 2008 non-R2 example to try. I'll need to ask about that 2008 64. The KB listed is for TLS 1.1/1.2 communication. Failing on a scan can be a variety of things. If you right click on the M icon in the system tray, you can generate logs for us to review the situation. A workaround for the short term would be to use the "MALWAREBYTES BREACH REMEDIATION (VERSION 2.X)" found under Endpoints \ Add Endpoints \ Dissolvable Unmanaged Remediation Tool, to scan the machine.

2008 and 2008 R2 are not supported by the 3.6 engine, they'll need to stay at 3.5. From the Cloud Admin Guide - https://www.malwarebytes.com/pdf/guides/MBQSG.pdfWindows Server 2008 R2 SP1‡§, 2008 SP2 ‡§, 2008§‡ Microsoft patch KB4019276 must also be installed and enabled§ As of July 2018, development has halted for Endpoint Clients using this operating system

Is this 2008 32 bit?

Hi @EthicalPrivate, can I have you unhide system files/folders and look for a folder called MBDDBin on the desktop? If it is there without the D&D tool running, delete it, and then grab a new download of the tool from the cloud portal and run it again.

Hi @redsoxfan, it is currently metered. The machine must be able to access and transfer over data from sirius.mwbsys.com. If you perform a new install, it will pull the latest right away with no meter right now.

I'm still working on this JCourtney, I hope to have something here son.

If you are on MBMC 1.9, definitely utilize the new service startup type and failure restart options on the general page in policy, this is exactly what those are meant to fix, especially with Win 10. The startup delay option under the Protection tab is for conflict/performance issues against Anti-Malware's web blocker and malicious file blocker with other security program during logon.

Good find, that's our comm service, though when it is off, they usually just show as offline, not unregistered. Another thing you may see is laptops may have double entries, one for the ethernet and one for the wifi. Which ever NIC was in use during deployment will have that MAC saved to the machine, when it is on the other NIC, it may show an unregistered entry along with its checked-in entry.

I know there can be local time versus UTC time discrepancies, the 17:15:45 to 17:15:42 is close enough that it was just likely some network lag time for that. If it perked up and saw those ip test blocks, I'm inclined to lean towards there just not really being any hits earlier that day to report.