SANS 504 Notes - Containment/Eradication/Recovery

Notes

• Containment
• need to stop the bleeding
• phase after an incident is declared
• consists of short-term containment, system back-up, and long-term containment
• First step, record incident details
• category
• criticality
• sensitivity
• Follow notification procedures based on incident details
• notify IR team
• notify management
• notify business units
• create / log IR ticket in appropriate system
• Initial Analysis
• remember, attacker might be watching for signs of IR, so be stealthy if you can
• Short-Term Containment
• prevent further damage, but try to keep the system intact
• best case, network changes to isolate the system
• worst case, pull the power (lose volatile memory)
• Deploy tracking files (WordWebBugs) to track data transit
• Might need to coordinate with ISP
• System back-up
• If possible, create a forensic image
• acquire logs and review, check neighboring systems 
• Long-term Containment
• generally required if you cannot turn off / repair / patch machine in a timely manner
• lots of techniques, mostly around changing trust relationships, etc of the running system
• During containment, be careful to jump to conclusions on who/what/when happened
• take detailed notes, but don't make assumptions
• Eradication
• two main goals
• remove attacker artifacts
• determine entry point
• virus scanning, rootkit detection, rebuild from a zeroed drive
• Improve defenses based on understanding the entry point
• perform vulnerability analysis
• Recovery
• decide when to restore, keep in mind business priorities
• monitor systems once they are put back in production
• build a script to check for initial attack vector (or for artifacts of the attacker) to return

Some thoughts on Azure

From an Azure point of view, at least in the IaaS sense, most of the techniques described here are similar.  Of course, there is limited access to the networking logs, so one would have to get creative with that part. NSGs offer some diagnostic logs, but not as detailed as we would require.  Windows firewall logs might be of use, but once again, doesn't show enough information regarding successful connections.

Containment could be as simple as deleting the NIC from an IaaS machine, or placing a NSG around that particular VM limiting it's access to the network.

Eradication and Recovery for IaaS are almost the same as on-prem.  In certain cases, depending on how you have your systems configured, a better approach is to rebuild from latest image + DSC for the application.  You could also be restoring from Azure Backup or a 3rd party backup tool.  

SANS 504 Notes - Identification (Azure VM analysis)

In this section I'll detail out my notes on the identification part of SANS 504.  I'll also have a look at a brand-new Azure VM and have a look at what is running.

Notes

• Identification is everyone's job
• Consider all the sources you can use to identify / detect an incident
• help desk
• firewalls
• IDS/IPS
• log alerting software
• anti-virus
• end users
• Consider the identification areas
• network perimeter
• host perimeter
• system-level
• application-level
• Incident handlers job to investigate an incident
• ensure all information provided is as current as possible
• send two handlers if possible (one to run the incident and one to maintain communications)
• set expectations up front around documentation and communication schedules
• ensure out-of-band communication channels are open (fax/phone/etc)
• enforce a need-to-know policy, keep rumours at bay
• Handlers need to have an understanding of a baseline of a system to look for differences
• SANS has published windows/linux cheat sheets that give some basic commands for initial investigation
• Things to look for
• Unusual process/services
• Unusual files
• Network usage
• Scheduled tasks
• Accounts
• Log entries
• Other unusual items
• Handler has to know when to declare an incident
• Don't fear to report early, worst case incident becomes a training event
• Need to do proper investigation on an event
• check for simple mistakes
• "what other possibilities are there"?
• Determine how much damage has been caused
• risk of the systems affected (and the reach)
• complexity of the attack (script kiddie vs real hacker)
• remote exploit?
• See https://zeltser.com/security-incident-questionnaire-cheat-sheet/ for more info
• Remember to maintain chain of custody and take good notes

Looking at a new Azure VM based on template

In this section I'm going to use some commands from the windows cheat sheet to have a look at a net new Azure VM.

The first is a look at the running services in an Azure VM.

Azure VM - Running Services

A couple of interesting things to note:

• Hyper-V services are installed, dead give away of the hypervisor technology in use
• Azure services (Guest/Telemetry) are enabled by default

Now let's have a look at which features are installed by default.

Azure VM - Installed Features

A pretty small set of features is installed.  Most are required because I am running a GUI and not a nano/core install.  It has been a long time since I've installed/used a windows server not on Azure, so I'm not sure what the base feature set is.  There are some interesting ones such as "Enhanced Storage".

Next, let's have a look at network connections.

Azure VM - Network Services

Looks like by default my Azure VM is talking out to the internet.  Curious, wonder what that could be.

Process ID - 1972 = WindowsAzureGuestAgent

Process ID - 2844 = WaAppAgent

IP Address 168.63.129.16 = http://whatismyipaddress.com/ip/168.63.129.16

IP Address 40.78.112.72 = http://whatismyipaddress.com/ip/40.78.112.72

The second address appears to be a link to the storage stamp associated with this VM.  The first, based on the waappagent logs, appears to be the fabric address. 

Azure VM - WaAppAgent Logs

Okay, cool cool.  Good to know that I need those connections and, further, that they are persistent even after initial setup.  This is obviously only true if you have installed the guest agent.  You can choose to opt out of this install.

Lastly, lets have a look at the scheduled tasks that have triggers and are not disabled.

Azure VM - Scheduled Tasks

There are probably a few other things we could check.  According to the cheat sheet, we should also have a look at large files in the system, registry keys, and local user/group memberships.  I'll leave that as an exercise to the reader :)

SANS 504 Notes - Process/Preparation

Well, my GCIH certification is up for renewal this year.  This time, since it has been a while since I've reviewed this material, I decided to redo the exam rather than the alternate renewal options.  As such, I'll be starting a series of notes for the SANS 504 course notes.  I remember taking this course way back when, it is a super exciting course and I highly recommend it.  It gives a good base on how to run an Incident and the steps involved.  Ultimately, the tools discussed in this course are real world, and give a ton of insight into how to defend networks/systems against them.

This post will be some points in the first section, around the incident handling process and the preparation phase.

• What is incident handling
• an action plan for dealing with the misuse of computer systems and networks
• generally a set of written policies and procedures that outline what to do when an incident occurs
• Pre-planning of response parameters/controls/scope
• An incident refers to an adverse event in an information system or network
• implies harm or the attempt to do harm
• contrast to an event, which is any observable occurrence in a system or network
• Ultimately, the definition of which events are classified as an incident is up to the handler and the company
• Think of incident handling as first aid
• incident handlers need a easy method to follow under pressure to resolve issues
• Core Stages: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned
• Preparation Phase
• The WHY:  You need to enable the enterprise, both technically and from a people perspective, to respond to incidents.
• People
• Focus on training (sometimes reoccurring training)
• Test user and the team often
• fake incidents
• social engineering attacks
• Establish communication mechanisms (easy to use) for end users to report suspicious activities (TSA: See something, say something policy)
• Coordinate with helpdesk staff (they are often the first line of defense against this)
• establish training plans
•  Policy
• Policy should be established
• in general
• consequences of insider actions 
• share information with authorities (or not)
• peer notification
• understand breach laws
• Warning banners allow for lawful recording of actions (also serves to remind users, like airline safety training)
• Get management buy-in and delegation of authority to the incident response teams
• Notes
• maintain excellent notes, preferably in written form on notebooks
• understand the chain of custody requirements and follow procedures
• Management Support
• work to achieve management buy-in
• show quarterly reports on incidents
• Building A Team
• aim for a multi-disciplinary team
• technical domains (server, network, storage, forensics, etc)
• Non-technical domains (marketing, law, public affairs, etc)
• Establish roles if no specific members exist and assign the responsibility to someone
• Conduct routing training and testing with the team
• many online resources (counterhack challenges)
• conduct sessions on log reading, etc
• Establish appropriate compensation plans (work times, etc)
• Establish response times, response locations
• Might need a command post (secure location to sore files and hold meetings)
• Remote people may be required to be the "techie on site" 
• Establish a budget for the team ahead of time (no need to seek approvals to spend during an incident)
• Checklists
• Have a firm understanding on how to rebuild systems from known good backups or from scratch
• Emergency communication Plan
• Create a call list, test this call list
• identify requirements for secured communication channels (ahead of time)
• Granting access
• have an access strategy in place for incident response team members to access critical systems and data
• Jump Bag
• thing about the things you will need in an incident
• Tailor this to your environment
• Technology: Gold images, rootkit checkers, debugging tools, forensic tools
• People: clothing, medications, food, etc
• Other things: cd/usb/media, jumpers, extra harddrives, taps, laptop with multiple OS, call list, cell phones with extra batteries