Date post: | 17-Jan-2016 |
Category: |
Documents |
Upload: | jonas-barton |
View: | 221 times |
Download: | 0 times |
Jim PaynePrincipal Security Relationship ManagerMicrosoft
After the Cyber AttackA Framework for Compromise RecoveryNeil CarpenterPrincipal Security Escalation EngineerMicrosoft
Way back in the year 2000…Microsoft published “The 10 Immutable Laws of Security”
If a bad guy can alter the operating system on your computer, it's not your computer anymore
Immutable Law #2
A bad guy could have altered the operating system on EVERY computer on your network
What If?
Typical Intrusion
Compromise goes back a year or longer
Use of privileged accounts that could modify any system on the network (e.g. domain admin)
Discovered by chance or external notification
Responding Resources in a state of crisis, shock, or disbelief
No practical backup from before the intrusion
Traditional DR plans don’t work
Common IssuesManaging disclosure of the incidentTelegraphs plans to the attackerPressure to “do something”Lack of follow-through beyond the initial crisis
What is recovery?Successful recovery requires a holistic approachAdversary no longer in control of systems or accounts
Better protected against re-compromise attempts
Better able to detect re-compromise attempts
Information preserved for future investigation
There is little point in building walls around a castle when the bad guy is already inside the gate
Even if you get rid of the adversary they will attempt to regain access and they succeeded before
0-days are real and you cannot guarantee perfect protection
Frequent desire to continue investigation long after the recovery
Phases of Engagement
Incident Response How they got in and
what they did* Identify attacker tools
and access Known compromised
hosts and accounts Extent of potential
compromise given access obtained
1-2 weeks
Tactical Recovery Remove known attacker
access points Plan then act at once to
maximize disruption No guarantee of
complete eradication 2-12 weeks
Strategic Recovery For when attacker has
had broad or unlimited access
Requires rebuilding of most systems
Must plan for safe interaction
Performed in phases starting with high value assets
Months or Years
Tactical Recovery
Defining “known compromised”Hosts where any of the following are trueDirect evidence of an attacker logging on to that system with admin credentials“Net use” is not the same as a logon in this caseAttacker tools installed that would have required admin access
Accounts where any of the following are trueAttacker was seen logging on with that accountAccount was used as a service, batch, or shared local account on a compromised hostAny account that performed a non-network logon to a known compromised hostAccount credentials were in an account database that known to be exfiltrated
Forest-wide account resetsWhere possible this is the preferred approachMany large enterprises unwilling or unable to do soCreates an exception to the rules given that the AD DIT is typically exfiltrated
Tactical recovery processIdentify targets for actionUse the definition of “known compromised” to select targetsThis can vary among customers but must be a realistic size
Create the plan for each targetIdentify and document “action packages” for each target assetUse the CHIM framework to identify actions
Prepare the environmentCreate as much of the action packages as you can ahead of timeMust be careful not to alert the attacker to your plans
Execute the recovery planOn the “plan execution date” disable, act, reenable targetsMust be performed near simultaneously to disrupt the adversary
Identify Plan
Prepare Execute
Developing action packages with CHIMCaptureSteps you will take to regain control of the target assetOnly a couple options here and only one good one
HardenActions we will take to try and prevent recompromiseAvoid broad network changes that will take a lot of time
InvestigationAcquire any information needed for future investigations before disrupting the environment
MonitorAttackers will typically try to reacquire the same assetsImplement increased monitoring on those targets to detect
Capture Harden
Investigation Monitor
Capture plan options
Rebuild hostRemove known malwareDecommission
Create new accountReset passwordDelete account
Attackers can persist in many ways
Operating systemUser profiles and stateApplication stateData
Don’t perform a full restoreInstall from trusted media/imageScan all data being migratedDelete user profiles
Inspect application state
Hardening optionsHost options are customer and target dependent
Upgrade OS and apps to latest version
Disable or randomize local administrator
Block workstation to workstation comms
Block admin Internet access
Block servers from connecting to the Internet
Applocker for whitelisting on server
Disable remote service install
Disable event log clearing
Enforce interactive logon with smart cards
Remove “Everyone” access from the network
Account optionsIncrease password complexity for service/admin accounts
Two-factor auth*
Restrict which systems accounts can logon to
Remove certain logon privileged (logon as service)
Dedicated Admin WorkstationsPrivileged Access Workstations
Investigation options
Forensic Disk Image
Seize physical machine
Save relevant logs
Monitoring options
Windows
New privileged accounts or logonsAppLocker in audit mode for suspicious processesService installationLogons to renamed hosts
Applications
Network
Application specific auditingAnti-malware logsIIS Logs
Monitor known Command & Control (C2s) with firewall/proxyIDS to detect exploits/C2 traffic
Tips for tactical recovery successCreate a communications plan earlyAvoid planning on compromised infrastructureDetermine disclosure criteria and team membersHave a plan should broad disclosure occur
Pick actions that are realistic in the plan timeframeAvoid large sweeping changes that distract from the tactical goalAvoid large scale rebuilds without well defined criteria
Pick a realistic target setNeeds to be as complete as possible but not so big as to be impossible to accomplishAvoid the temptation to investigate foreverRemember attackers have to manage their targets
Perform and dry run and test preparations
Strategic Recovery
Strategic recovery modelsTwo models for regaining trust in all systems
The Onion
Regain control of systems by working in rings or tiers of access
Requires coordinated action within in each tier to assure success
Better suited to smaller environments
The Ark
Start fresh with a new environment
Opportunity to perform major upgrades
Start with most valuable assets and expand over time
Care must be taken in how assets are migrated and how they interoperate
You can do both but ½ + ½ = 0
The Onion Model
TiersAssign resources to tiersSystems are placed in initially placed in tiers by their role
Tier 0 – domain controllers
Tier 1 – shared servers
Tier 2 - workstations
Accounts that are admins on tier N resources are also tier N
Any system a tier N account logs on to becomes tier N (or lower)
This is recursive and accounts are assigned the lowest tier numberAccess: Users and Workstations
Power: Domain Controllers
Data: Servers and Applications
Example: enumerating tier 0
Domain AdminsEnterprise Admins
DC Service
Accounts
Workstations
Logs on to
Domain Controllers
Admins Service Accounts
Also used on
WorkstationsServers
Remediating a tierMinimize assets in target tierWhere possible remove shared accounts and systems
Suspend accounts in target tierPrevent the adversary from using accounts during remediationNetwork disconnect another option
Remediate target assetsFor tier 0 start with the DCs and then all other systemsFollow up by remediating accountsUse CHIM framework and methodology
Resume operationOnly enable target accounts once all systems they will log on to have been remediated
Minimize Suspend
Remediate Resume
The Ark Model
Building the arkStart small and iterateEasy to get overwhelmed by the scope of the effortWork in small manageable groups and learn from the experience
Create don’t migrate accountsIdentify trusted account info sourceNeed to identify all users that require access
Source hosts aren’t trustedFollow the same CHIM methodology to build new hostsCan you trust the data you are migrating?
An ocean filled with sharksPlan for long-term safe interoperation
Protect credentials from exposure
Minimize trust in data and applications
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.