'Lazy' Hackers Exploit Microsoft RDP To Install Ransomware (sophos.com) 72
An anonymous reader writes:
An investigation by Sophos has uncovered a new, lazy but effective ransomware attack where hackers brute force passwords on computers with [Microsoft's] Remote Desktop Protocol enabled, use off-the-shelf privilege escalation exploits to make themselves admins, turn off security software and then manually run fusty old versions of ransomware.
They even delete the recovery files created by Windows Live backup -- and make sure they can also scramble the database. "Because they've used their sysadmin powers to rig the system to be as insecure as they can, they can often use older versions of ransomware, perhaps even variants that other crooks have given up on and that are now floating around the internet 'for free'."
Most of the attacks hit small-to-medium companies with 30 or fewer employees, since "with small scale comes a dependence on external IT suppliers or 'jack-of-all-trades' IT generalists trying to manage cybersecurity along with many other responsibilities. In one case a victim was attacked repeatedly, because of a weak password used by a third-party application that demanded 24-hour administrator access for its support staff."
They even delete the recovery files created by Windows Live backup -- and make sure they can also scramble the database. "Because they've used their sysadmin powers to rig the system to be as insecure as they can, they can often use older versions of ransomware, perhaps even variants that other crooks have given up on and that are now floating around the internet 'for free'."
Most of the attacks hit small-to-medium companies with 30 or fewer employees, since "with small scale comes a dependence on external IT suppliers or 'jack-of-all-trades' IT generalists trying to manage cybersecurity along with many other responsibilities. In one case a victim was attacked repeatedly, because of a weak password used by a third-party application that demanded 24-hour administrator access for its support staff."
Re: (Score:3)
Re: (Score:1)
They shouldn't have been exposed to the internet in the first place. Have anyone who wants to connect to a machine on the lan/wan connect to the network via VPN first
You are assuming there IS a VPN, though and in many smaller organizations that is not the case.
Re: (Score:2)
Shows the flaws of account lockouts if they permit someone to launch such a trivial denial of service against your organisation.
Re: (Score:2)
The point is that small organizations don't usually allow for specialization of duties, and that means less brains working on different aspects of IT.
The additional expense of maintaining staff or services that mitigate the risk of your business getting ass-raped by malware is either worth it to a business owner, or it's not. Small organizations that choose the latter usually become victims. Fuck 'em if they can't learn from best practice.
No one can do it all, it's similar to medicine - no doctor does all parts. It takes about 250 specialists to comprise all aspects of medicine, and that number is increasing daily.
See? There are areas of business that value risk mitigation. 250 specialists exist because when someone in medicine tries to "do it all", it usually ends with a wrongful death lawsuit. Medicine was forced to learn
In the ass (Score:2)
Re: (Score:1)
Two obvious possibilities.
I've seen both, often.
Re: (Score:3)
There needs to be accountability for third party vendors who insist on insecure configurations like this...
The trouble is most of their customers don't have the knowledge in house to realise how insecure it is. I've encountered a few vendors who made ridiculous demands like this and their response has always been "but our other customers dont have a problem".
They want 24/7 RDP or VNC access direct from the internet, won't use a vpn (which to be fair, having 100 clients each using a different vpn technology
Re: (Score:2)
But still, letting 3d party full access to your servers/infrastructure must sound off some alarms at even "stupid company"?
I often face the opposite problem, which is that if the customer would just open a temporary ssh or rdp session then I could quickly fix a problem that they themselves struggle for weeks on end to solve. That or IT departments that refuse to open ports in their FW because they made their decision back in 1975 on which protocols to allow. But then banks/finance is a conservative industry
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"Lazy" hackers? (Score:2)
You're either a hacker or you're not.
What the article talks about isn't hacking. It's using what actual hackers have made/found to maliciously exploit software for their own purposes/enjoyment.
I don't practice hacking, but I have a pretty deep respect for the actual hackers. Most of the time the when the mainstream media uses the term, they're referring to script kiddies.
It shouldn't have to be repeated on a site like this that hacking isn't necessarily malicious by definition.
since "with small scale comes a dependence on external IT suppliers or 'jack-of-all-trades' IT generalists trying to manage cybersecurity along with many other responsibilities.
Not just the small scale busin
Re: (Score:2)
Most of the time the when the mainstream media uses the term, they're referring to script kiddies.
Alas, we do not get to decide what terms stick and which ones do not. Like it or not, "Hackers" is a negative label, they are seen as criminals, end of story. "Script kiddies" never caught on the mainstream, if you use that, 99% of people won't know what you're talking about.
I believe the current euphemism for "good guy hackers" is "Security Analyst" or whatever other euphemism you wanna pick. They're not hackers anymore, those are the bad guys.
Re: (Score:2)
I'm pretty sure there is no real euphemism for "good guy hackers," at least in the mainstream. The hacking community itself of course has whatever labels ("white hat" vs "black hat" or you still occasionally see "hacker" vs "cracker" or whatever.) But the mainstream doesn't really care about a guy who's legitimately hired to do penetration testing and doesn't exploit the weaknesses he finds, so they don't really need a common term for the role.
I used RDP ... (Score:2)
What I did was go to the registry and change the standard port from 3389 to the last 4 digits of our front office telephone and block 3389 inbound/outbound at the firewall.
Those with remote desktop privileges had to append the new port to the RDP request:
173.234.22.16:9182
That stopped that shit.
Re:I used RDP ... (Score:5, Funny)
Thanks, I have noted down that number now.
--your friendly network neighbourhood hacker.
Re: (Score:3)
Re: (Score:2)
Thanks, I have noted down that you are gullible.
--your friendly network neighbourhood administrator.
Realsies (Score:3)
You're assuming it's not a honeypot?
Re: (Score:3)
Switching the SSH port is helpful as well, if you expose port 22 at all to the outside world. So is blocking and forcing users to use specified, non-standard VNC ports: too many personnel at home use that to work their way around workplace password management. I've personally encountered too many IT personnel who slip past their own workplace access policies by slipping a VNC installation onto their most critical servers, so they can access it as needed or share on-site screens with offsite access.
When in a
Re: (Score:2)
Switching SSH to require keys and to reject password auth helps a lot...Although some very stupid brute force scripts will keep trying and cause unnecessary load... Some scripts are even aggressive enough to dos the ssh service.
Re: (Score:2)
That can be a useful step. There are tradeoffs. I've had difficulty discouraging SSH users from storing passphrase keys locally, and on remote gateway hosts they wish to SSH _from_ in the field without bothering with ssh-agent.
Re: (Score:2)
I don't use ssh-agent, rather i use the ssh config to specify using another instance of "ssh -w" as a proxy in order to connect to specific hosts, that way the intermediary host is basically just used as a proxy and your local device still authenticates to the far host even if there are one or more intermediary hosts in the way.
Re: (Score:2)
What I did was go to the registry and change the standard port from 3389 to the last 4 digits of our front office telephone and block 3389 inbound/outbound at the firewall.
This is a good idea. I personally never leave any sort of potentially hazardous service on a 'known' port. Never the default. Yeah, it's security via obscurity, but a little of that never hurts anything. Just be aware, a determined attacker can scan your ports and find where you moved it to. But it does defeat most of your run-of-the-mill cookie cutter hacking.
Moving services to non-default ports is a great way to fly under the radar of most simple attack vectors. But still, firewalls, isolation of ou
Re: (Score:2)
Your points are well taken.
The RDP attacks, however, were simple (back then) and scripted.
It's sorta like having burglar bars.
Crooks will pass those up and look for easier targets.
Re: (Score:2)
Those with remote desktop privileges had to append the new port to the RDP request:
173.234.22.16:9182
That stopped that shit.
Very clever, if that IP address points to your competitor or NSA.
Very dumb if it is really pointing to your own server.
Re: (Score:2)
Why would it be clever if it pointed somewhere else?
That does not get me in.
And, foreign (and even domestic) intruders don't bother looking for misdirected ports.
There are enough easy targets on 3389.
Re: (Score:2)
foreign (and even domestic) intruders don't bother looking for misdirected ports.
This is horribly incorrect and I hope you're not responsible for putting production servers behind a 'misdirected port' as there are plenty of port scanners that will identify RDP, SSH, etc., on non-standard ports and will attempt to bruteforce them with common name dictionary attacks for the username and whatever it is they're doing with passwords.
I have an RDP honeypot setup on one of my home IPs so I can observe the behaviours of trojans, hackers, etc., and with my RDP hosted on a port higher than 10,
So... (Score:2)
Is that RDP thing on by default on Windows 10?
Re:So... (Score:4, Interesting)
No, it's not. But it's _very_ common to activate it foe personnel who use their more powerful desktop systems for telecommunication. It's also very standard to enable for Windows hosts in a machine room, unless you've the time and resources to set up a remote KVM or the hardware based remote consoles such as DRAC. Those hosts are often surprisingly vulnerable. The various security improvements of a server environment can be overwhelmed by the unwillingness to update, and reboot, production servers. It's also often overwhelmed by the need to support older software. I _still_ see critical XP systems in unprotected internal networks, used for legacy software or proprietary software for which an upgrade is very expensive.
3 ways to crack (Score:5, Interesting)
Correct me if I am wrong, but there are three basic ways to crack a password.
1) Brute force - the answer to this is long passwords and to have each password attempt take twice as long as the last. I.E. The second attempt after a failure waits 5 seconds. The third attempt takes 10 seconds, the fourth takes 20 seconds, etc. For password length you can use an md5 hash of a selected read -only file. If the system is set up right it will take less mouse clicks to do than the 8 keyboard clicks currently used
2) Social Engineering - the answer to this is a two factor token system, preferably a key fob rather than just using the phone which is easily lost, stolen, or compromised. Can easily be combined with the increasing time method above.
3) Password lists (either stolen or public). Outright forbid the 10,000 most common passwords and tell people that if they reuse the same password, they can be fired from their job and can not sue. Don't blame the company when the user is stupid.
Note that it is NOT a requirement to change the passwords often, as long as you obey the three requirements above, changing the password can be done once a year without affecting safety.
Re: (Score:2)
Correct me if I am wrong, but there are three basic ways to crack a password.
You missed the most often used method: Find a broken service to exploit for code execution on the target. No passwords needed, system hacked.
Re: (Score:2)
"2) Social Engineering - the answer to this is a two factor token system, preferably a key fob rather than just using the phone which is easily lost, stolen, or compromised. Can easily be combined with the increasing time method above."
According to my password safe I have over 100 passwords. Are you really advocating I cart around a wheelbarrow full of key fobs as the solution?
Never going to happen. NEVER.
And the worst part is that a fob doesn't even stop social engineering attacks.
"Hi Alice I'm Bob from IT
Re: (Score:2)
Over a network biometrics have to be converted to digital data, basically a key or a hash which can be attacked in the normal ways.
Also once compromised, biometrics remain compromised forever...
Re: (Score:2)
Over a network biometrics have to be converted to digital data, basically a key or a hash which can be attacked in the normal ways.
Yes. That's why I wrote there were implementation and other problems.
Also once compromised, biometrics remain compromised forever...
That's only a problem if you use it as a 'secret password'. Its more like your username. And its value is not that it is a secret but that it is (ideally) difficult to forge.
Re: (Score:3)
V......P.....N (Score:4, Interesting)
Oh for crying out loud people. Don't open RDP ports direct to the internet!
If the average Joe can use a VPN to pirate movies I should think YOU could use it to secure your damn network!
L8r.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
Setting up a VPN host is a lot more challenging than setting up a VPN client, unfortunately. I mean it probably doesn't have to be, but currently it is.
Part of the problem is Microsoft. There's a lot of VPN routers out there that have fairly easy VPN setups.. for IPSec-style VPNs only. And Windows doesn't easily support those out of the box. So you can setup PPTP (or L2TP or similar) client in Windows pretty easily, and you can setup IPSec in routers pretty easily. Neither really play well with the oth
VPN suggestions seem... no better? (Score:2)
Re: (Score:2)
Re: VPN suggestions seem... no better? (Score:2)
Re: (Score:2)
Re: (Score:2)
You'd setup up a VPN to use certs instead of passwords, which are much more difficult to brute force...
Even if you successfully got access to the VPN, you'd then only have access to the RDP port which means you now have a second target to attack, so it adds an extra line of defence. And hopefully a competent sysadmin would notice VPN logins from unexpected locations.
Re: (Score:2)
And if you have *ACCOUNT* lockout policies then you get a dos attack instead...
And brute force attacks can still succeed because you just try lots of usernames with a small number of the most common passwords.
Account lockouts are stupid, you want to block the source of the attack (as well as using stronger authentication than passwords on any externally facing system).
TFA is garbage (Score:2)
The only way an RDP session is being successfully initiated from outside your WLAN is if there's port forwarding setup on your router or you have a static IP direct to your computer. In nearly every other case, you're behind a NAT, which would allow you to initiate a RDP connection but not receive. On the router or firewall, remove any forwards and/or disable any sort of DMZ, and you're OK.
"Sophos security experts" aren't cited as saying anything about this, because of course, the recommended method of medi
Re: (Score:1)
Re: (Score:2)