LabCorp hacked via brute force RDP
-
All LabCorp drug tests are in stasis right now waiting to see what information has been compromised. Thousands of drug tests will likely have to be redone.
-
@Polygeekery
Guess that guy with thehunter2password is gonna get fired.
-
Seems like they were mostly on the ball, at least as far as their response. I'm amazed that they didn't at least lock out those accounts after a few bad login attempts. Assuming that brute force means the obvious.
-
They were probably just trying to prove that, no, they didn't owe $500 in drug tests.
-
@boomzilla said in LabCorp hacked via brute force RDP:
I'm amazed that they didn't at least lock out those accounts after a few bad login attempts.
On SBS the account lockout policy won't apply to default admin. So you're supposed to disable it and use a surrogate domain admin account (which is a good idea anyway). I wonder if the same is true on the full-fat versions of Server, might explain it.
-
@boomzilla said in LabCorp hacked via brute force RDP:
I'm amazed that they didn't at least lock out those accounts after a few bad login attempts. Assuming that brute force means the obvious.
Yeah, that seems like a no-brainer.
-
@Cursorkeys said in LabCorp hacked via brute force RDP:
@boomzilla said in LabCorp hacked via brute force RDP:
I'm amazed that they didn't at least lock out those accounts after a few bad login attempts.
On SBS the account lockout policy won't apply to default admin. So you're supposed to disable it and use a surrogate domain admin account (which is a good idea anyway). I wonder if the same is true on the full-fat versions of Server, might explain it.
I touch Windows as little as possible and I don't administer anything other than personal machines but I'd be pretty paranoid about anything exposed to the intertubes.
-
@izzion said in LabCorp hacked via brute force RDP:
@Polygeekery
Guess that guy with thehunter2password is gonna get fired.The great thing about an unlimited-attempt brute attempt means that it's going to be the guy with the
Hunter222password is going to be fired.
-
@cursorkeys said in LabCorp hacked via brute force RDP:
On SBS the account lockout policy won't apply to default admin.
Fuck that. Instead lock out by IP.
This remote IP failed a RDP check X number of times? Fuck that IP. BLCOKED AT FIAWALL!
-
That won't help with a malware that's running on plenty of compromised machines everywhere in the world, and so can use plenty of different IPs.
-
@zerosquare said in LabCorp hacked via brute force RDP:
That won't help with a malware that's running on plenty of compromised machines everywhere in the world, and so can use plenty of different IPs.
It'll help.
Also it should trip an IDS that raises an alarm that the same account has had multiple failures from multiple IPs in a short period of time.
-
@Cursorkeys said in LabCorp hacked via brute force RDP:
@boomzilla said in LabCorp hacked via brute force RDP:
I'm amazed that they didn't at least lock out those accounts after a few bad login attempts.
On SBS the account lockout policy won't apply to default admin. So you're supposed to disable it and use a surrogate domain admin account (which is a good idea anyway). I wonder if the same is true on the full-fat versions of Server, might explain it.
That's why it's good idea to Deny remote login with "Domian Admin" group
Seriously, the only time you need to login with those accounts are when you need to login to domain controllers to work, and you login there with network-enabled KVM that on subnet not accessible from public.
-
@cheong said in LabCorp hacked via brute force RDP:
@Cursorkeys said in LabCorp hacked via brute force RDP:
@boomzilla said in LabCorp hacked via brute force RDP:
I'm amazed that they didn't at least lock out those accounts after a few bad login attempts.
On SBS the account lockout policy won't apply to default admin. So you're supposed to disable it and use a surrogate domain admin account (which is a good idea anyway). I wonder if the same is true on the full-fat versions of Server, might explain it.
That's why it's good idea to Deny remote login with "Domian Admin" group
Seriously, the only time you need to login with those accounts are when you need to login to domain controllers to work, and you login there with network-enabled KVM that on subnet not accessible from public.
I dunno, A network KVM just seems like RDP with more steps. If you have a sane setup, administrative ports won't be accessible from non-admin computers/VLANs anyway and certainly not exposed to the interwebs.
-
@Cursorkeys said in LabCorp hacked via brute force RDP:
I dunno, A network KVM just seems like RDP with more steps. If you have a sane setup, administrative ports won't be accessible from non-admin computers/VLANs anyway and certainly not exposed to the interwebs.
The problem is that, by default domain admin accounts can be used to login any workstations/servers in the domain, therefore if any of them has RDP port opened for external access, they can be used to try passwords of these accounts.
With the policy that I linked to, these machines no longer could be used to try passwords of domain admin accounts, so there would be one less attack vector.
-
@Zerosquare said in LabCorp hacked via brute force RDP:
That won't help with a malware that's running on plenty of compromised machines everywhere in the world, and so can use plenty of different IPs.
I dare say that if the number of allowed attempts is sufficiently low then you'll run out of IP addresses faster than you can bruteforce the password.
-
@cheong said in LabCorp hacked via brute force RDP:
@Cursorkeys said in LabCorp hacked via brute force RDP:
@boomzilla said in LabCorp hacked via brute force RDP:
I'm amazed that they didn't at least lock out those accounts after a few bad login attempts.
On SBS the account lockout policy won't apply to default admin. So you're supposed to disable it and use a surrogate domain admin account (which is a good idea anyway). I wonder if the same is true on the full-fat versions of Server, might explain it.
That's why it's good idea to Deny remote login with "Domian Admin" group
Seriously, the only time you need to login with those accounts are when you need to login to domain controllers to work, and you login there with network-enabled KVM that on subnet not accessible from public.
Oh god no. That is a horrible idea. It could make things more secure but at the cost of massive amounts of productivity.
-
@Polygeekery said in LabCorp hacked via brute force RDP:
Oh god no. That is a horrible idea. It could make things more secure but at the cost of massive amounts of productivity.
It shouldn't. I largely agree with @cheong here -- accounts in the Domain Admins group should be used only for administering the domain (e.g. via ADUC), not for logging in to member servers. My clients don't allow the Domain Admins group to be in servers' local Administrators groups (this is better than denying remote login for a number of reasons); there should be some more specific project/team - Member Server Admins group instead.
Then again, we also use different user accounts for enterprise admin, domain admin, member server admin, workstation admin, etc. It complicates account management somewhat (once on onboarding, once on offboarding) but limits damage if an account (especially a member server admin account) gets compromised.
-
@heterodox Yup. Folks from Sysinternals created this with a reason. You should rarely need to logon any other machines with domain admin accounts.
