次の方法で共有

A necessary component to any IR: Containment

  • [アーティクル]

This blog is updated at https://ciberesponce.com

Incident Response and Containment

Anyone who does Incident Response (IR), or any Digital Forensics Incident Response (DFIR) process knows that collecting Indicators of Compromise (IOC) is only half the story.  Eventually, you'll need to recover the environment, which inherently means you best have confidence in the IOCs and have a plan to evict the adversary.

Before we go into detail on just how to do that, it is paramount to talk about containment.  Anytime a recovery team comes in and takes intel from the IR team, a plan must be executed while being sensitive to the control-plane an adversary should have after a step has been executed.  For example, if Exchange environment and the general Users population gets compromised, one should not just cleanup the Exchange environment, but they should also protect it from being re-contaminated by potentially other compromised areas of the environment.

So, we do this very important task via Identity-containment methodologies.  What you will find, though, is that this doesn't just give us containment but also gives us higher assurances that we discovered the IOCs against a particular actor(s).  This additional detection mechanism can give any response team the greenlight to either get the IR team back involved as adversarial activities are still being discovered after an eviction attempt or identity potentially dangerously configured applications (or perhaps an admin who exposed the wrong cred to the wrong system).

How to build containment

An often-underutilized policy that allows us to dictate who can logon to what system is User Rights Assignments.  In addition, User Rights Assignments are only useful if we can target machines, which is where Organizational Units (OUs) come into play.  Lastly, Security Groups come in handy to group various users (and potentially other Security Groups) together, so we can assign policy to them.

Every “container” we want to make, needs an OU.  For example, we need an OU for Tier-0.  We would then assign policy, via User Rights Assignments, so only Tier-0 credentials can logon to those machines; it would be denied from authenticating against the other OUs.

That said, for every container we need:

  • An OU (to target computers)
  • A Security Group (to bundle users/Groups together)
  • A User Rights Assignment policy properly linked and configured

Since Denys take precedence over Allows in ACLs, not only do we want to allow Tier-0 accounts to log into Tier-0 machines (identified via an OU), we want to also deny them from logging in to the other OUs.

This is the premise of containment, at the Identity level.  There are other methods of containment, including Network, however, network containment is often not enough in the world of credential harvesting.

A last note about Containment.  Once we put these policies in place, we can actually see adversaries try to break out of our newly built containers using technologies like Azure Security Center.  Once we collect all these events, we can look at Event ID 4625 and look for particular “Failure Reason”.

Note again that these actions shouldn’t be done until the IR team has finished its investigation.  This doesn’t mean the “hunt” is over; many times, during the recovery, additional IOCs can be discovered as containment methodologies and hardening guidance are put into place.

Any Failure Reason with the value "%%2308", or in English, "The user has not been granted the requested logon type (aka logon right) at this machine", should be a red flare in the sky.  It should be followed up on, in coordination with the IT staff.

Lastly, containment methodologies can and should be applied to service accounts as well as local accounts.

Service accounts

Since service accounts are also harvestable, and typically have privileges across multiple computers, they are prime targets for adversaries to laterally move.  Besides using Azure ATP to detect anomalous behavior of such accounts, User Rights Assignments can also be used to ensure Service accounts act like Service accounts; that is, they can’t be used to RDP or any other interactive logon.

User Rights Assignments can also help drastically increase visibility into an environment during the IR.  If you are unable to still find how the adversary is in, but there are indications they are still in, use these to pinpoint exactly where they are and continuously harden the environment.  Eventually you’ll pinpoint the location of the adversary while at the same time executing critical Tactical Recovery steps.

Any breaks from this policy either means foobar happened (or a bad application using a service account interactively) or an adversary is actively trying to break out of the credential containers URA’s help create.

One should use Azure Security Center and Log Analytics to peer into these events.

Local Accounts

You should ensure Local Accounts that are Members of the Local Admin Group (S-1-5-114) cannot be used to laterally move.  Local accounts should only be used in Break Glass scenarios.

Refer to Aaron Margosis’ blog on this topic: https://blogs.technet.microsoft.com/secguide/2014/09/02/blocking-remote-use-of-local-accounts/

Note that this doesn’t prevent local admins from logging on remotely, it just means the accounts can’t be used to ‘hop’ after the initial logon.  In addition, this only pertains to Windows 7+ as the new SID wasn’t backported to all Operating Systems.

When this approach is used, Local Accounts can’t be used to laterally move—forcing the adversary to use other means, such as domain accounts.  This increases our Return of Investment (ROI) on technologies such as Azure ATP, which log domain user activities.

 

Now you have a building block to build a more confident recovery effort.  Of course, prevention (which provides additional detection/awareness and visibility as well) isn't a be-it-all solution.  A perfect complement to containment is continuous monitoring capabilities looking for malicious activity based on behavior, specific Azure ATP and Windows Defender ATP.  These solutions should be used starting from the IR and throughout the Recovery process (and ultimately passed that to prevent this from happening again!).

 

Happy hunting!

Andrew

Comments