This post is more like a collection of notes that I have found useful, this page will have a focus on incident response.

Order of Volatility

This identifies the order in which data should be preserved when first accessing a system. As a rule of thumb, unless there is absolutely a good reason to, don’t shutdown the system. Instead consider other ways of isolating it. These practices should be defined before the incident happens. However we know that this may not be the case in practice. Consider the possibility that this may also alert a TA to the actions you are taking. This may force a TA to change tactics and strategy. For example, they may simply be looking for persistence at the time you have discovered the abnormality. If they are spooked then the strategy may become destructive to avoid detection.

Keep in mind that the system is compromised, and you have lost all trust with every application that is running on the system. In short, the system no longer belongs to you!

Here is the order of volatility from the IETF:-

When collecting evidence you should proceed from the volatile to the less volatile. Here is an example order of volatility for a typical system.

– registers, cache

– routing table, arp cache, process table, kernel statistics,
memory

– temporary file systems

– disk

– remote logging and monitoring data that is relevant to the
system in question

– physical configuration, network topology

– archival media

https://datatracker.ietf.org/doc/html/rfc3227#section-2.1

Certain tools will be used for the collection of data that help to preserve the integrity of collected information.

For instance Volatility https://github.com/volatilityfoundation/volatility https://www.volatilityfoundation.org/ can be used for memory forensics. You may find that End Point agents collect data about unknown applications and their execution or EDR can be used to create Virtual isolation of the system, to avoid any further interaction with the rest of the network.

Having a method for access to the system is important, and you can leverage other tools to offer a way of gaining access during tough times.

Here are a list of tools that can be used in Memory Forensics when connecting to a Physical system.

• FTK Imager
• Redline
• DumpIt.exe
• win32dd.exe / win64dd.exe
• Memoryze
• FastDump

For Virtual systems consider capturing the memory file e.g.

• VMWare – .vmem
• Hyper-V – .bin
• Parallels – .mem
• VirtualBox – .sav file *this is only a partial memory file

Communication Map

Defining the communication map before an incident is one of the most important activities I think any organisation can perform. Having this laid out means you are able to contact the right people at the right time. This will enable you to get better feedback and quicker decisions made through out the response play.

I think most organisations will forgive a poor escalation vs a missed incident, though it isn’t something you want to be doi9ng all the time. This is why a plan is formed that defines the escalation process. A good plan will identify triggers and thresholds, however with that said, if you spot something happening and you believe the right thing to do is open the comm plan, then do it.

Following the communication map, a team can quickly be assembled, much like in avengers endgame with the portals (god I love that scene) and now the incident can be managed. Each escalation point will know who they are responsible to contact and get out of a project …. or bed.

Ultimately in serious incidents, a you need multiple heroes to help fend off the attack.

In most plans I have seen a tree structure is created which helps the organisation identify the next step.

The Emergency contact list should include names, emails, and number of people to contact. It is STRONGLY advised that this document is stored Physically… you know if your data is inaccessible or gone… well yeah it’s inaccessible or gone!

Make sure the right teams have access to this list, and responsible parties know how to get access to it.

NOTES ABN (always be takin’ notes)

Document what is happening

A good IR plan template I have found is here :-

https://github.com/cydea/ir-plan

I recommend checking it out as it covers a variety of subjects, and is great for understanding what information is important.

Here are two of the checklists. First is important to the Initial Incident tracking

• Who reported or what led to the discovery of the event?
• Where (systems, networks, users) does the event affect?
• What are the consequences of the event?
• How was it discovered?
• What are the related, and potentially exposed, devices, systems or networks?
• Has the source(s) of the events been identified?

Here is a process to follow during incident Triage.

•  Log the incident
•  Record the source of the incident
•  Record details and what is known about the incident
•  Form a working hypothesis for the incident
•  Assign an incident severity
•  Assign an incident category
•  Escalate or notify (as required)
•  Mobilise Virtual IR Team based on type and severity of the incident
•  Consider the need for third-party support
•  Consider need for Legal involvement
•  Consider the need to notify any customer(s)

Also try to keep track of your reasoning, things are going to be hectic, and what you thought was a good idea may be questioned. If it is, this is to identify what lessons can be learned and how things either went well, or could be improved for the next time.

OH, ALWAYS BE USING UTC

UTC (Aka Universal Time)

This is a very high level look at some of the things you would need to do in a response. Again there will be a team, and if there isn’t a process you should look to create one.

Importantly, you need to know

How to secure the evidence

When to alert others, and how

How you will isolate the incident, whether that is via Virtual, Physical, or network Segmentation.

when to invoke Business Continuity, though you would have like escalated before this occurs

And ALWAYS be taking notes.

Controlled Isolation

One final note, be careful. You may want to understand an attackers strategy and motivations before taking actions defined in your plans. This Should also be Part of the play book for deciding how to respond and what to do next. You could reach organisations like Mandiant to assist with understanding the attacker and working in an effective way to eliminate the threat.