Microsoft closes off two avenues of attack: Office macros, RDP brute-forcing(theregister.com)
theregister.com
Microsoft closes off two avenues of attack: Office macros, RDP brute-forcing
https://www.theregister.com/2022/07/22/microsoft-windows-vba-macros/
12 comments
One of the latest avenues is sending the malicious macros in ISO files masquerading as legitimate documents or zip files. Ideally, email filtering would block that attachment type across the board, but they definitely get by some platforms. What's more is that 7-zip-unpacked files lost their Mark-of-Web, leading to easier execution of malicious scripts as well (although I don't think 7-zip is a significant attack vector in many environments, since it's a non-default option.
I have had luck with isos as well because motw publisher check isn't done for exe's in them. But unless you have an encrypted zip, our email security will catch it before/after delivery and quarantine it after detonating the iso and its contents. I even tried stuffing the iso with very large files to hit some sort of a limit in automated analysis.
Why not just make a simple script to do that? I wrote one in Python ages ago to add up's to the firewall that tried various names, failed # of logins etc... Nothing a few hours of scripting can't solve!
Not that simple in a bigcorp. A 10 line script is a year long project if someone else does it. I am not a sysadmin or dev, even if i was i don't work for every team with random public facing cloud vms.
With their insistence on Microsoft accounts, Microsoft could solve the macro issue by providing a certificate infrastructure making it easy to prove who created the active content in the document.
Instead they either require the writer to jump through impossible hoops or train the user to ‘fix’ the document by blindly clicking the yellow bar, which forces the user to take a responsibility he can’t responsibly take.
Instead they either require the writer to jump through impossible hoops or train the user to ‘fix’ the document by blindly clicking the yellow bar, which forces the user to take a responsibility he can’t responsibly take.
Good point, especially if a document is hosted in O365 (onedrive or sharepoint). Signing it should be easy, they already have version control.
Interesting policy change for RDP
'The default policy for Windows 11 builds – specifically, Insider Preview 22528.1000 and newer – will automatically lock accounts for 10 minutes after 10 attempts to sign in fail. Users can tweak this, changing the number of failed sign-in attempts that trigger a lock and how long the account will be locked.'
'The default policy for Windows 11 builds – specifically, Insider Preview 22528.1000 and newer – will automatically lock accounts for 10 minutes after 10 attempts to sign in fail. Users can tweak this, changing the number of failed sign-in attempts that trigger a lock and how long the account will be locked.'
Wait, RDP has been around since the last century and they're just now adding this? What a signal.
There are a lot of attempts to brute for 3389 RDP and 5900 VNC, I see them on all my nodes tarpit rules. For completeness sake I should add that people should not depend on this blocking as the 10 minute account lockouts will only stop targeted attacks and not all the bots. Some of the better written bots ...admittedly there are not many, distribute their attempts across many targets reducing the probability of a lockout. For clarity what I mean is that they might brute force several hundred thousand IP addresses they found 3389 open on but only hit each unique IP once every {interval based on number of targets}.
In my opinion the windows machines should be behind a VPN or at least a firewall that restricts access to known CIDR blocks to limit the number of bots that could reach it.
Another option that will take away the non-targeted bots is the same method used by many in SSH and that is to change the listening port for RDP. [1] This is security through obscurity and works like a charm when putting nodes behind a VPN is just not possible. e.g. change 3389 to something like 33389. This will not stop a determined attacker but will most certainly cut out 99+% of the bots and remove logging most events and reduce risk of alert fatigue. This will also keep the non-targeted bots from locking out your accounts and creating support headaches. To see what ports nmap scans by default i.e. ports to avoid on a modern version of nmap, use:
And lastly if you don't RDP into your machines then make sure remote desktop and all other remote access services are disabled. Check what is listening with
Always back up your registry and create a restore point if you intend to make changes to the registry.
[1] - https://docs.microsoft.com/en-us/windows-server/remote/remot...
[2] - https://docs.microsoft.com/en-us/sysinternals/downloads/
In my opinion the windows machines should be behind a VPN or at least a firewall that restricts access to known CIDR blocks to limit the number of bots that could reach it.
Another option that will take away the non-targeted bots is the same method used by many in SSH and that is to change the listening port for RDP. [1] This is security through obscurity and works like a charm when putting nodes behind a VPN is just not possible. e.g. change 3389 to something like 33389. This will not stop a determined attacker but will most certainly cut out 99+% of the bots and remove logging most events and reduce risk of alert fatigue. This will also keep the non-targeted bots from locking out your accounts and creating support headaches. To see what ports nmap scans by default i.e. ports to avoid on a modern version of nmap, use:
nmap -v -oG - | grep "Ports scanned"
And lastly if you don't RDP into your machines then make sure remote desktop and all other remote access services are disabled. Check what is listening with
netstat -nabo
Always back up your registry and create a restore point if you intend to make changes to the registry.
[1] - https://docs.microsoft.com/en-us/windows-server/remote/remot...
[2] - https://docs.microsoft.com/en-us/sysinternals/downloads/
For RDP, ugh.... yeah. Lockouts are kind of a problem, I had to deal with this months ago. Lockouts bu themselves are a security issue because availability is a security property. Now, if Microsoft allowed RDP to have OpenSSH like controls about how many failed attempts result in a delay that would be nice. What would be even better would be password policy enforcement especially and specifically for the RDP local group. And password spray protection for domain accounts (if an IP fails login from multiple hosts, temporarily block the IP instead of locking the account). My last wishlist would be public key authentication that is easy to setup like SSH.
You can easily enforce password policy for weak passwords but this lockout policy is useless if they are spraying leaked/known passwords against many accounts, if I understand correctly all you have to do is avoid repeat login attempts for any one account within a 10min window? Which makes it harder but still practical.