AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
![]() ![]() In a coming article, and in my upcoming book, I’ll talk more about the tools and Python scripts they use to accomplish these brute force techniques. Also, the lengthy duration in between those attempts prevents lockout of the account. By spreading out the attempts and rotating the usernames, the login failures look more organic and benign to an IDS. ![]() In many cases, different usernames are interleaved with one another. They rotate through username password combinations, trying the same username a few times over an extended period of time (30 minutes, 1 hour, 3 hours). ![]() When you look at these login trials and geolocate their origin, you see bunches of different IP addresses from across the world. They leverage botnets or similar to make RDP login attempts originate from many different machines.How are hackers / nation state actors / cybercriminals getting around account lockout policies? They do several things: That’s why month after month we read about one company after another getting PWNED by ransomware and/or their sensitive data getting exfiltrated, where the initial attack vector was RDP. By that very nature it makes it harder for an IDS system to detect. I’m sure there are some IDS vendors out there that have developed better detection algorithms for RDP brute force attacks, but the most sophisticated modern brute force attacks are designed to blend in with normal background login failures from users. It’s truly an arms race right now between black hat hackers and IDS vendors, in terms of attack techniques versus IDS countermeasures and detection algorithms. What About Intrusion Detection Systems? Will They Help? Modern RDP brute force attacks, as I will now demonstrate to you, skirt around all but the most draconian of account lockout policies, rendering them hopelessly ineffective.If your RDS environment is linked to your domain, an RDP-originated lockout can effectively prevent them from accessing any other services. It also increases workload for your admins in general, as a certain percentage of your user base (gotta love the ID10T users) will always fat finger their passwords and lock themselves out.It sets the stage for an eventual DDOS (Distributed Denial-Of-Service) attack that can lockout wide swaths of your user base, creating a huge headache for your admins and service desk help techs if/when that occurs.In fact, in a Remote Desktop Services environment, aggressively defining account lockout policies can have several serious consequences, and is largely ineffective. Nowadays, with the proliferation of single sign-on authentication and unified account directories like Azure Active Directory, defining aggressive account lockout policies as a prophylactic security measure no longer makes sense in many circumstances. Account Lockout Policies – No Longer a Panacea… and Often a Liability!īack in the late 90s, when I was a young whippersnapper of a college network admin (this was in the wild west days of Windows NT 4.0), defining and setting account lockout policies at the domain level was a commonly accepted best practice. I’ll share real samples from the login failure tables that my Remote Desktop Commander Suite software maintains to prove my point. ![]() The purpose of this article will be to show you how SOPHISTICATED brute force hacking attempts against RDP have gotten in recent years. ![]()
0 Comments
Read More
Leave a Reply. |