Today, I'd like to discuss a few of the Critical Controls, and how I see real people abusing or circumventing them in real companies. (Sorry, no code in today’s story, but we do have some GPOs )
First, what controls are on the table today?
First, let’s talk about admin folks. In this first situation, we've got helpdesk and IT folks, that all require elevated privileges. This client did the right thing, and created "admin accounts" for each of those folks - not all Domain Admin, but accounts with the correct, elevated rights for each of those users.
Back in the day, these users were then supposed to use "run-as" to use those accounts locally. These days however, it's recognized that this “plants” admin credentials on the workstation for Mimikatz to harvest, and also starts an admin-level process for malware to migrate to. Today's recommendation is that users should run a remote session to a trusted admin station, which doesn't have email or internet access, and do their admin stuff there.
This means that those "admin" accounts have a list of stations that they are permitted to login to – ideally only servers (not workstations). You can enforce this in AD with a Group Policy:
These controls also mean that you need to disable internet access on your jump hosts for admin sessions. This might be an uphill battle, but we’ll get to why it’s important. This is also easy in a Group Policy:
So, what could possibly go wrong? ... let’s count the ways J
1/ Remember, these are admin folks. So they've got the rights, and they also get impatient with extra work. So, the natural inclination is to exempt themselves – maybe create a new group with admin rights, and move their account into that group. That gives them admin login to workstations, and also gives them internet from the jump hosts.
2/ You’ll also see at least some of those folks "Connect" that admin account to their exchange mailbox. That gives them email from their admin account
voila! Now they are logged in all the time as admin, and checking email as admin. So now, when that user receives a Word or Excel file (or whatever) with a macro in it, then open the file and run the macro, that macro is running as (in this case) Domain Admin. Which of course means that (yes in real life) the customer’s Domain Controller got ransomwared (along with all of their other servers actually).
3/ Again with the extra work theme - the admin in question was using the "jump host" as they should be, but needed an attachment from an email that they got during a support call. The right way to do this is to open the mail from their non-privileged account on their non-privileged workstation, collect that file, map a drive and copy it over. Or if it's text, just copy/paste that info into their admin "window" that's running on the jump host. (Same procedure if it’s a downloaded file from a vendor support site or whatever)
What happened instead? They fired up a browser and browsed to their OWA server from that jump host! This means that again, they're checking email as admin. Worse yet, it's on the actual admin host, where *all* of the admin accounts are, so Mimikatz can now collect *all* of the admin account credentials!
How can we protect against these? For IT admins, often your only protection is audit and logging. You should be tracking creation of new groups, and any changes to admin accounts (group membership for starters). You can do this with audit policies in AD, but you’ll need a decent central logging and alerting process so that the right folks get told when your admins “color outside of the lines”. This seems like real “mom and apple pie” advice, but it’s more complicated than it sounds. I took SEC 555 (https://www.sans.org/course/siem-with-tactical-analytics/type/asc/ ) when I attended SANSFIRE this year, it was a real eye-opener for me as to how to assemble all the pieces to accomplish this sort of thing.
On the email thing, blocking OWA from the admin stations is likely a good idea. You can do this using host based firewalls, or you can properly segment your network – isolate your user stations from your servers for starters, and start on a set of firewall permissions between user stations and servers, and from servers to user stations. Because every user does not need tcp/1433 to your SQL servers, every user does not need tcp/445 to every server, and your Accounting Group, Receptionist and Visitors don’t need login access to your vCenter server.
Wait, we just dragged some new controls into the mix with this discussion – it’s funny how when you try to control a problem, often the list of controls that you think you need is not the complete list:
How about non-admin people in your organization?
Say you have a good spam filter, and you're blocking office macros on inbound emails. Or, more typically, you're permitting macros inbound from a few partner organizations (where IT always loses the battle), and the business has "accepted the risk" that macro-based malware from those partner orgs is not blocked. But in either case, an office document with a macro from some "random source email address" is not getting in.
You'll always have targeted folks for things like this - in many organizations, that will be the CFO or people in accounting (who can transfer dollars), or in healthcare it will be the head of nursing (who has access to all health records) or the folks in charge of dispensing pharmaceuticals. In any organization, it's also recognized that the CEO and Sr Management (all the folks who’s names in posted on your website or are easily found with Google or LinkedIn) generally have the rights to ignore or bypass policies, so they'll be targeted as well. In addition, you’ll have those users who are always after the “cracker jack prize” in the email - once they start, they’ll click as many times as necessary to get there (see Xavier’s story yesterday https://isc.sans.edu/forums/diary/May+People+Be+Considered+as+IOC/25166/ ). Word does get around – if you have folks who always open attachments and click links, your adversary likely has them on a list - you might call it “market research” or “knowing your demographic”.
Anyway, you'll have a targeted person, and the attacker will have some in-band (ie email) or out of band (phone, facebook messenger, linkedin or whatever) access. At some point, the attacker will realize that their malware isn't getting into the organization via email. So, what will they suggest? "Let me send it to your personal email" will often be the first suggestion. Your target will then pick the malware up via webmail. The other out-of-band methods will often be the second choice - linkedin, facebook messenger, or other social media "email replacement" services.
How can this be prevented (at least partially)? If you’ve got a Content Filter on your firewall or proxy server, you can usually block “Web Mail” as a category. Similarly, you can usually differentiate between an app (for instance Facebook) and the messenger within that app (Facebook Messenger), and have different block/allow rules for each. You’ll always have some folks that need things like the LinkedIn “InMail” application, HR in particular. You really are stuck with GPOs and AV in that case. If your organization does have partner organizations that use macros, likely HR does not need those. Using GPO’s either block HR people from running macros entirely, or only permit them to run internally signed macros.
Which brings 2 more controls into the mix:
In addition, within your SIEM you likely want to elevate the priority of any alerts from folks that have access to sensitive information, have elevated admin rights, or are known “clicky-clicky” folks. You might call this “CVSS for people”, and you wouldn’t be far off the mark on that. Alerts might include suspect email attachments, script or macro activity, failed logins, unusual IP addresses (on VPN connections or VDI for instance). We obviously care about these alerts for all users, but we should care a bit more if that user is an IT Admin, is a Sr. Manager, or “clicks that link” every Tuesday (again, Xavier has some great pointers on this here https://isc.sans.edu/forums/diary/May+People+Be+Considered+as+IOC/25166/ )
This adds a few more controls the first two we’ve already added (but it’s worth bringing these up twice!), the third is new. No SIEM is “set it and forget it” – in this case you are raising the priority of events involving specific users, but “adjusting” your SIEM is an ongoing process. There are always new attacks, new ways to detect attacks, or new methods of combining multiple logs to create a better view of a problem.
Defense of your environment is a continual thing, and it’s constantly evolving. Do you have any stories that you can share that are related? Have I missed an obvious control in the situations I’ve discussed? Please, use our comment form and share!
Jul 25th 2019
9 months ago
For your “Deny Domain Admin On Workstations” GPO, consider adding a WMI filter (i.e. ProductType=1) to it to prevent the GPO from applying to servers, no matter where the GPO is linked.
Jul 26th 2019
9 months ago