Jump to content

MrJBK

Honorary Members
  • Posts

    21
  • Joined

  • Last visited

Reputation

0 Neutral

Recent Profile Visitors

648 profile views
  1. that's precisely what I did. It's working now, as I mentioned in my last post ... but I'd really like to understand why adding the .xls files that triggered the exploit detection to the "Allow List" didn't solve the problem by itself.
  2. Everything was working fine, then bang, another update (to ver 4.4.6) last week, and the same workbook was trapped as an exploit (see log txt file). I beg to differ with your diagnosis regarding reset to defaults (in the link you provided above). I tried it... RET ROP detection is off and it still triggers an exploit.Adding the macro worksheet to the "allow list" does nothing. MBAM still crashes excel when macros1.xls load he only way to make it stop is to disable "Office VBE7 abuse prevention" and "Excel Macro 4.0 abuse prevention" MBAM excel macro workbook blocked.txt
  3. Pretty sure it was on default settings to begin with. The only way it works is if I disable the VBA7 exploit, which is what I indicated in my very first post.
  4. Hi Exile, exploit block txt file and support tool .zip files attached. MBAM vba7 exploit history log item 20200921.txt mbst-grab-results.zip
  5. I have a number of .xls files that have macros. Two of them are loaded at excel start-up. Both were able to load with no complaints. Today, MBAM did an update, and now both are being flagged, and it shuts down Excel immediately. I was able to get past the problem on the first xls file that loads (this is in my Xlstart folder), by adding it to the "Allow" list. The first file (macros1opener.xls) opens macros1.xls. Although I also added macros1.xls to the Allow list, it still triggered the "Exploit Office VBA Abuse" block. I have managed to override this by disabling Office VBA7 abuse protection. A rather blunt instrument . MBAM broke something with this last update. Please help.
  6. Hi Maurice, Thanks so much for the confirmation and guidance, and your forbearance through this case. I think you've given me enough ammunition so that I can defend against the attacks. For the moment, I'll use the following strategy: 1. Until I need to have Remote Desktop running, I'm turning it off. 2. I have pulled all of the IP addresses from the 524 .json files in [C:\ProgramData\Malwarebytes\MBAMService\MwacDetections] and used VBA in Excel to create a manageable list to use for blocking... I was going to add them to the block list, but since there are almost 100 unique addresses, and each IP address requires adding an individual rule (several clicks, etc.) that would be very time consuming, and probably not worth the effort. I have attached the .xls file that I used to summarize the data in the .json files. The VBA programming is not terribly professional... but it serves my purposes. The compilation of the RTP alerts over the past several months is interesting. There are a number of port 3389 alerts coming from IP address that I do not recognize... these are most likely break-in attempts. I have attached the .xls file that I used to summarize the data in the .json files. Thanks again for all of your help. GetMBAMLogs.xls
  7. Hi Geoff, Thanks for your input. I just read this article: https://tweaks.com/windows/50743/change-remote-desktop-rdp-port/ which kind of explains why there might be so many inbound attacks being flagged by MBAM. It also has a more thorough explanation of how to change the port in Win 10 (there is no setting... it has to be done through the registry). It also describes what needs to be done if I'm trying to connect to remote desktop from the RDP client... which is essential. What's really odd about this problem is that I have another Win10 computer with MBAM which is not showing similar alerts. The only difference I can figure between the two is that 3389 routes to my desktop (the one that has the constant alerts) so any brute force attempts to hack in through the internet all hit the desktop through 3389. RDP host is enabled on both machines, but I only connect to the laptop through the LAN. Since there's no way to reach the laptop through the internet, I guess that gives it some protection. Interestingly enough, I've had RDP enabled on my desktop all morning so far and only had one alert, and it was not the same type. The multiple alerts that were occurring over the past week were like this one: Category: Compromised Domain: IP Address: 77.108.68.42 Port: 51618 Type: Inbound File: C:\Windows\System32\svchost.exe The only alert this morning was: Category: Trojan Domain: cdn.tweaks.com IP Address: 104.28.31.23 Port: 443 Type: Outbound File: C:\Users\jklein\AppData\Local\Google\Chrome\Application\chrome.exe The disappearance of the constant alerts may be due to a change in MBAM's definition files. I noticed that there was an MBAM update this morning at 7:33AM and the original problem now seems be gone. -Jon
  8. Hi Maurice, I re-enabled Remote Desktop, and sure enough, I started getting MBAM alerts : I also did some searching and found this post: which sure sounds exactly like what I'm getting. I've disabled Remote Desktop again, and, of course, the alerts stopped. So this problem has everything to do with Remote Desktop being enabled. I'm guessing that something changed in MBAM, since the post above seems to have started around the same time I saw the same problem. I use Remote Desktop from time to time, especially when I'm travelling (which I haven't been lately due to Covid-19) . I'd like to keep that functionality. What do you think? MBAM RTP 20200510 946PM.txt
  9. the block events ended ... but I think it's because I disabled Remote Desktop... I've completed the TrendMicro scan. It only found 1 threat... which I think is in the recycle bin... I'd like to re-enable Remote Desktop and see if the events re-appear. I'll try that now after rebooting, and let you know what happens tomorrow. Thanks again!
  10. Attached is the MBAM scan results. Again, nothing found. MBAM Scanner report 20200510.txt
  11. Hi Maurice, OK... Attached is the scan result from the Microsoft Safety Scanner. I ran it only on my C drive (500G SSD). My D drive is big (1TB), (nothing from D is ever loaded into memory). Scanning D takes a long time. Other than this forum, I'm not doing anything with the web today. msert.log
  12. Oh... I forgot to mention... one of the things I did last night was to disable Remote Desktop, with the thought that maybe some bad actors were trying to come in through that door, which may have been causing the MBAM warnings. I will re-enable it later today after I do the scans that you're suggesting and let you know if the warnings come back. I guess I shouldn't have done 2 things at once. Makes it difficult to determine which one was the root cause.
  13. Hi Maurice, Ran ESET overnight. Attached is the log of what it found. The files on the D drive are old installers and I think many are false positives. In any event, they are never run. I re-enabled notifications in MBAM, and I'm not seeing the pop-ups anymore. After sending this post I'll reboot and see if things are still well-behaved as the day progresses. I truly appreciate the time and energy you've put into this! ESET scan log.txt
  14. I already did a full offline scan today. It came up with nothing.
  15. I've had the notice show up even when my browser is closed.. wasn't playing online games. All my messaging apps were closed. I had already set MBAM to hide notifications when Chrome is full screen. I have now set the "Show notifications in the Windows notification area" to off. Still don't know why it's detecting all of these events, though. It's a little worrisome. It makes me think that there's some kind of malware that's inviting attacks. One of the things I will try is to disable remote desktop hosting and see if it stops. If you have any other ideas... I'm open to suggestion.
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.