pbust

Staff
  • Content count

    3,355
  • Joined

  • Last visited

About pbust

  • Rank
    Staff

Profile Information

  • Location
    Earth

Recent Profile Visitors

109,868 profile views
  1. Thanks Noctsol. Unfortunately there is no way to exclude individual scripts like these. Allowing Excel or Excel macros to execute a scripting program is a very large security hole which is currently abused by malware writers as an infection vector. The only other way is to create a new Policy with the anti-exploit shield disabled for Excel, and add only the machines that need to execute this script to that particular Policy.
  2. MBAM 3.0 and av-comparatives.org

    Re: MBAM and Defender, they are 100% compatible. We are using the interfaces available only to AV to manage the registrations and status updates of MBAM in the Windows Security Center. Only Microsoft approved antivirus providers can do this. The difference is that by default we install side-by-side with Defender (even though this behavior can be changed under Settings) as we've always believed that a layered approach is always preferable to relying on a single product. Re: testing methodologies, we've also always been up front about our disagreement with third party testing vendors (and AMTSO). We disagree with the fact they don't test vector blocking defenses (i.e. not full product), we disagree with their selection of samples (most of the times older than 1 month, no real focus on 0-day effectiveness), we disagree with the "pay to see misses" business model, and we disagree with the use of simulators which do not behave like real malware does nor does it simulate the infection vector. These are typical practices found in most if not all of the 3rd party testing companies, where each testing company incorporates at least two of the above practices. AMTSO, since its inception, hasn't been able to influence any significant change in AV testing in its entire lifespan. AMTSO doesn't have teeth and has failed on its original mission of improving and evolving AV testing. None of the above should be news to anybody. We've been pretty open and upfront about our views all along. We don't expect everybody to agree with us, but this has been the position since the beginning of Malwarebytes and, even though we will be participating shortly in 3rd party testing, our views about their business model still remain the same. In summary, if you're a troll, move on and stop spreading FUD. You're not welcomed here. To everybody else, if you have questions or concerns about how Malwarebytes replaces and improves your AV, or our views on AV testing, we have been and remain open to having an honest and transparent conversation. Feel free to PM me and I will gladly try to answer any and all concerns you might have about our technologies or our views on testing.
  3. MBAM 3.0 and av-comparatives.org

    Thank you, I feel the same way. We're being extra careful of not just adding blot to meet the test demands. In most cases, the samples tested by 3rd party labs are samples which have long been dead. We'll play the game, but without adding unnecessary bloat.
  4. MBAM 3.0 and av-comparatives.org

    Ahh, sorry, I thought you were also called Sveta (I've spoken to Sveta @ MRG few times before).
  5. MBAM 3.0 and av-comparatives.org

    Hi Sveta, as we've said many times, we don't agree with most testing methodologies out there as they consistently don't test any of the vector blocking capabilities of security products. MB3 relies heavily on vector blocking for early detecting and blocking of modern threats. Yet most labs, including MRG, grab the last stage payload and funk around with it and just test it against the on-access and post-execution protection layers, completely bypassing the vector blocking capabilities which could have stopped the threat in the real world. Malware spreads using certain techniques which are blocked by MB3, and neither MRG nor any of the other labs replicate those real-world environments, and ergo do not test the full product, only portions thereof. We will be participating in more lab tests shortly and biting the bullet of adding unnecessary bloat to the product to entertain these unrealistic tests and test fanboys, but that doesn't mean that we agree with them. Their testing methodologies are all ~10 years old.
  6. Just send everything within C:\ProgramData\Malwarebytes\MBAMService\Logs\ (path may vary depending on the product version)
  7. Hi. Please attach your endpoint detection logs. There are two advanced settings that can be tweaked to allow these type of actions. But we'll need the logs to figure out which one it is.
  8. IMPORTANT: Web Blocking / RAM Usage

    Glad to hear about the offline updater fixing it. As for deleting *.ref(s), the machine will need a reboot to recover after that. Simply deleting it won't solve the problem in most cases.
  9. IMPORTANT: Web Blocking / RAM Usage

    Good catch, I fixed it already. Are you seeing the script delete the *.ref file successfully or is it failing in that step?
  10. IMPORTANT: Web Blocking / RAM Usage

    In the documentation you can find this. http://downloads.malwarebytes.com/file/mbes_for_business Go to \Managed\Documentation\Managing MWB in Large Networks Best Practices.pdf Read Section 5
  11. IMPORTANT: Web Blocking / RAM Usage

    Updated guidance, tools, and processes have been posted in the following post: Please refer to the new guidance for any and all situations where the previous guidance was failing. Thanks and again, sorry for all the troubles this is causing people. We are deeply sorry and continue to work throughout the weekend and night to make things right. If you are still affected, please feel free to reach out to me directly at pbustamante@malwarebytes.com.
  12. In the early morning of Saturday, January 27, 2018, a faulty Web Protection update was released which caused a connection issue for many of our customers. As a side effect of the web protection blocks, the product also spiked memory usage and possibly caused a crash. We triaged the issue quickly and pushed a protection update on Saturday, January 27, 2018 at 10:48a PST. The affected products were Malwarebytes 3 Premium, Malwarebytes Management Console (MBMC), and Malwarebytes Endpoint Protection (aka Malwarebytes Cloud Console). Malwarebytes for Mac, Android, AdwCleaner, Incident Response and Breach Remediation were not and are not affected. For a complete description and root cause analysis please click here. Please note endpoints were not affected if they were turned off before Saturday, Jan 27, 2018 and then were not turned back on until after Saturday, Jan 27, 2018 at 11am PST. For affected endpoints, this thread is intended as recovery guidance. Guidance below applies to corporate customers using the on-premise Malwarebytes Management Console (MBMC) as well as corporate customers using the cloud-based Malwarebytes Endpoint Protection (aka Malwarebytes Cloud Console). If you're a home user and/or Malwarebytes 3 Premium user, click here for details on how to recover your systems. For corporate customers running the on-premise Malwarebytes Management Console (MBMC) In the Malwarebytes Management Console, edit the Policy and disable real-time protection Once real-time is protection is disabled and your clients can communicate, highlight the endpoints on the Client tab and click the Update Database button at the top. This should fix it for most endpoints. If any endpoints fail to get the update, you will have to force an update. This can be done locally on the endpoint or remotely over the network. Locally on the endpoint (logged in to the machine). You can point your endpoint users to do this themselves: Download and execute MBAM Rules Offline Updater Reboot the computer Remotely over the network Make sure your machine is on a non-blocked IP (i.e. 10.x.x.x or 192.x.x.x). Blocked IP ranges are from 128.x.x.x to 191.x.x.x. *NOTE* It is recommended to not use your MBMC server for this task Download the following script and extract it to a folder on your computer Create a file named hostnames.txt in the same folder, adding one IP per line for each of your endpoint IPs. You can export a list of IPs with the faulty update from the Management Console (sort by update version, select affected ones, copy, and paste into notepad). If your internal DNS is not on a blocked IP range, you can feed hostnames.txt with hostnames instead of IPs Edit the script and type in the *LOCAL* admin username and password for endpoints (i.e. NOT the domain admin) in the first 2 lines Run the batch file, which will delete the faulty database file and schedule a reboot in 30 seconds Once all the machines are updated, turn on real-time protection in the Management Console Policy settings. If the Management Server SQL database grows heavily and takes up too much space, feel free to truncate the contents of the TBL_ClientSecurityLog and TBL_ClientSystemLog SQL tables. Detailed instructions can be found in this document. IMPORTANT: this will remove ALL detection history and is irreversible. For corporate customers running the cloud-based Malwarebytes Endpoint Protection (aka Malwarebytes Cloud Console) In the Malwarebytes Cloud Console, go to Settings -> Policy and disable Web Protection and Self-Protection (if enabled). Do this for all the Policies On the Endpoints section, choose "select all" and choose "Check for Protection Updates" from the Actions button. This should fix it for most endpoints. If any endpoints fail to get the protection updates, you will have to force an update. This can be done locally on the endpoint or remotely over the network. Locally on the endpoint (logged in to the machine). You can point your endpoint users to do this themselves: Login to the machine and start a scan by right-clicking on the Malwarebytes traybar icon. This will force an update and fix the issue. Cancel the scan and reboot the machine. This should fix the problem in most cases. If the above doesn't work or the machine is unresponsive, download mbep-fixer.exe to your Desktop. If you want to deploy this over the network using SCCM or other similar platforms, you can use instead use mbep-fixer.msi. Execute mbep-fixer.exe. You will need to execute this as admin. Reboot. Remotely over the network Make sure your machine is on a non-blocked IP (i.e. 10.x.x.x or 192.x.x.x). Blocked IP ranges are from 128.x.x.x to 191.x.x.x. Download the following script and extract it to a folder on your computer Create a file named hostnames.txt in the same folder, adding one IP per line for each of your endpoint IPs If your internal DNS is not on a blocked IP range, you can feed hostnames.txt with hostnames instead of IPs Edit the script and type in the *LOCAL* admin username and password for endpoints (i.e. NOT the domain admin) in the first 2 lines Run the batch file, which will delete the faulty database file and schedule a reboot in 30 seconds Once all machines are updated and connecting correctly, go to the Cloud Console, Settings, Policy, and enable Web Protection and Self-Protection again. If the above guidance does not help and you are a corporate customer, please contact corporate-support@malwarebytes.com for further support.
  13. MBAE does prevent script-based drive-by downloads. If that's the method of distribution of the Meltdown/Spectre payloads, then MBAE should block it.
  14. Try creating a separate policy and assign just this server to the new policy. In the policy set the check-in interval to something like an hour or two. Does that alleviate the problem?
  15. Hi BRAM. The MBAE CLI are the configuration commands being executed from the Management Server. Those should only show up momentarily and then disappear by themselves. Try changing the check-in internal in the Management Console policy to something greater. That should ease up on the amount of commands being sent to the machine.