Discussion in 'Business & Enterprise Computing' started by NSanity, Jun 28, 2017.
Agreed, Don't do it without testing or understanding the impacts.
Logging of course helps, just to keep harping on about that. Privileged access management, monitoring of when psexec is used etc.
There was a post on r/msp that talks about "how do you restore all of your clients at once" or similar...
my response was this;
So recovery against this is irrelevant.
The single key part of this attack that will absolutely be part of most ransomware iterations going forward is the lateral movement through LsaDump across the network and poor privileged account management.
Its not how you plan to recovery 1 customer, or all customers in the first event. Its the second event. the Third. the fourth.
If you are restoring what is there - you are ABSOLUTELY just as vulnerable.
LsaDump moves through network hunting for privileged accounts - it just takes 1 computer without Windows 10/2016 with a service account with domain admin privs (or server then dom admin) or a tech with dom/server admin that disconnected without logging off or a client who uses dom admin as their daily driver and the whole network is fucked.
This is a very serious question we're asking internally - because literally every single client we have has a privileged account logged in somewhere for something. I can't think of a single client at my current gig that is immune once this shit is inside their network.
They are all literally living/dying based on AV/Spam Gateway.
We're having a meeting sometime this week to discuss how we deal with this - and move our clients to a new model that doesn't have this vulnerability.
Its fucking scary.
Does it need localadmin for lsadump?
yeh, but so does myob, and a metric shitton of smb-to-enterprise shitware.
And here is the conversation that is going to happen;
Us: We're killing local admin
Client: we can't be unsupport?!?
Us: But Virus.
Vendor: NEIN SUPPORT
Client: we need to find new MSP because change vendor >>>> msp or because we only have 1 possible vendor.
You just listed 95% of the computers on our network.
I'm always amazed at how much of a pain it is to ditch local admin for most orgs
If you aren't using LAPS and denying remote login tho...
And that's the thing right.
Even in the more secure/bigger orgs I've played in, this has been the case. There might be a solid effort to 'be good' about security and maybe you even have 3 accounts (user, admin, dom admin), but somewhere there is an account on an older piece of crap that is way more priv'd than it should be.
How many people here can honestly say they don't use Dom admin to join machines? Or even that you don't need to?
Will it drive a sufficient critical mass to go to their Vendors and say "Hai Guyz, Local Adminz is bad k"
enough so that shitware vendors stop including it as a requirement?
Fundamentally a business has still got to business right?
If there isn't a viable solution in the market place, just what the fuck do you do?
Given I've watch several vendors still refuse 2016 support 9 months of GA later (and close to 2.5 years of public technical previews), not to mention the vast amount that still require UAC disabled - just how fast do you think they can rework their shitware to *not* require local admin?
*cough* SCADA *cough*
A lot of that shitware doesn't have a lot of competition or it's so heavily ingrained it'll be hard to remove even if it's possible
They do, but how can they business when the Next laterally moving 'thing' fucks them? And upon investigation, it fucks them because Myob means they have to run local accounts as admin?
So now their choice is between, "Not Myob" or "No Computers at all"
So mister security man - besides isolation/air-gapping - dafuq do we do?
So for the average MSP to prove this is going to be hard. For the average MSP to be able to articulate this in the post-incident review in such a way that the client understands how they got fucked is going to be monumentally difficult. For something to actually get done about it?
No piss off Zee Russians? (or have anything they want)
Assume the brace position
(I've been up since 4, non shitposting will resume later)
Using nmap to scan for MS17-010 (CVE-2017-0143 EternalBlue)
Security attacks alone won't do this. And quite frankly, it's getting very boring to keep saying it, but vendors only give a shit about money.
Where do vendors get money? From customers. You want your shitty vendors to stop giving you shitty software, then you as a customer have to do something about it.
The most guaranteed method is to threaten to switch, and follow through.
The least guaranteed method is to whine about shit vendors on a forum where they can't read your posts, and keep paying them shitloads of cash every year for their crap software.
Make your choice.
Except the code is public now. Guess how many variants now have this in them.
Okay I'm in a taxi and have a coffee so less shit posting.
First of all lateral movement requires machines to have network level access to other machines. Dunno why in Pablo's case he's using psexec for deploying Adobe patches but my current workplace deploys them via software centre. So isolation between the local subnet. Hell if all else fails use host isolation and keep your psexec. Obviously monitor for psexec. Don't give local admins on a machine remote login rights in other workstations. If you must, log abuse of it. LAPS all the things. Iirc in newer domain compatibility levels you can set accounts to have extra protection too.
If you absolutely must have local admin grant it only to the users machine, obviously not practical if users change workstations.
Why the fuck you'd have domain admin interactively logged in anywhere...
Captures domain admin logins, monitor for usage spikes. Run bloodhound. Understand your weaknesses.
Get periodic pentests to see how you're going, they live for finding the stuff this exploits.
Seriously though if compromising a single workstation gets you domain admin start looking there and brainstorming how you can reduce privileges
There's been psexec malware before, just didn't work this well. These tools have been public and free for *years* and exploit weak network designs and poor privileged access management. Those can't be patched and take a long time to fix unfortunately.