Forensic analysis of a ramnsware attack

Is that examination post-exploit (held to ransom) or post-release (ransom paid or alternative method of release found)?

Are you examining disc memory or RAM or both?

Post-exploit and only disc memory for my thesis.

OK got it.

Do you think it is a useless thesis?

Absolutely not. Your idea for this thesis is worth pursuing.

Remember your contribution adds to the principle "one-thesis-attempts-to-improve-upon-another". As a researcher my image I have attached below might hopefully make that point clearer

I have a large research collection of materials about ransomware, so do ask if there is a particular point you seek clarification.

Lastly, I saw you intended to use Scalpel. That reminded me of a statement in the book - The Art of Memory Forensics - Detecting Malware and Threats in Windows, Linux, and Mac Memory (2014). Just in case you haven't read that book…

Occasionally, people still attempt to reconstruct a file from a memory sample using traditional file carving tools, such as Scalpel (https://github.com/sleuthkit/scalpel). In most instances, they attempt to run a carving tool directly against a memory sample. These tools linearly scan the data, looking for specific signatures associated with well known file formats. Unfortunately, most of these tools assume the file data is contiguous and that the media being analyzed contains a whole copy of the file. This is a problem when dealing with RAM because the data stored in physical memory is inherently fragmented, and only parts of a file may actually be loaded into memory. As a result, except for files smaller than a page of memory, you are probably not going to extract the data you expect.

Alternatively, it is possible to use a plugin like memdump to extract the virtual address space of a particular process, and scan it using a linear file-carving tool. Although this can help address the issues with non-contiguous data, you still may lose important context associated with non-resident memory pages.

Exactly. The premise is that the right precautions are immediately put in place before defragmentation begins.
The same applies to SSDs, which have the TRIM command. If TRIM is executed then all data will be lost.
Thus, this procedure will only be successful if it is done immediately.
In fact I will write this in the premises of the thesis.

That is not a premise, it is an assumption (and a "bad" one while we are at it).

The "right precautions" are EITHER
1) put in place BEFORE any ransomware attack is possible
OR
2) put in place AFTER a ransomware is detected BUT BEFORE defragmentation (or ANY OTHER filesystem/disk intensive activity) takes place

The problem with #2 is that a lot of time may pass between the ransomware starting encrypting all your documents and it being detected, the whole point of these ransomwares is that normally they are detected with some delay (when they finish encrypting and ask for the ransom) so if there is actually anything automated in the background or - like the example I suggested - a "huge" Photoshop session running, there will be a lot of damage done.

Besides, a number of the known "remedies" only work if you can image the memory and extract the decryption keys from it, whilst the only "really quick" way to stop a defrag, or the creation of temp files, etc. is that of "pulling the plug".

It is a hard decision to make, keep the system powered on, capture the memory and hope that a decryption tool exists or will come out or cut the power thus minimizing disk writes potentially destroying the original data (deleted but still - partially - recoverable)?

Before I forget, another variable, how does disk occupation influence the recovery?
I mean, is recovering files from a - say - 95% filled filesystem (5% free space) the same as recovering from a 25% filled system (75% free space)?

How would the number of "encryptable" files influence the behaviour?
I mean, if you have a storage disk with all .doc and .docx files, will it behave differently from a "normal" system disk with thousands of files that the ransomware won't touch?

I know that it seems like I am putting before you a lot of difficulties, but rest assured that it is only to help you consider as much as possible the different aspects of the matter before you take a path that you may later regret having taken.

jaclaz

QUESTION Would it be possible to roll back or restore Volume Shadow Copies to recover a non-encrypted volume? Or would the Volume Shadow copies themselves be encrypted as well by the ransomware and thus inaccessible to be even restored?

QUESTION Would it be possible to roll back or restore Volume Shadow Copies to recover a non-encrypted volume? Or would the Volume Shadow copies themselves be encrypted as well by the ransomware and thus inaccessible to be even restored?

ANSWER yes and no.

Most ransomware will attempt to delete existing shadow copies, many using vssadmin, one of the suggested forms of preventive protection is to rename or disable, etc. vssadmin.exe
https://www.bleepingcomputer.com/news/security/why-everyone-should-disable-vssadmin-exe-now/
some use instead wmic shadowcopy delete /nointeractive (but both need the VSS service running), one approach is to only enable the service when creating a shadow copy
http//itsimple.info/?p=1180

Recovering their contents from a deleted shadow copy may be possible or it may not
https://i.blackhat.com/us-18/Thu-August-9/us-18-Kobayashi-Reconstruct-The-World-From-Vanished-Shadow-Recovering-Deleted-VSS-Snapshots.pdf

(again if it has been not overwritten by *something else*)

jaclaz

Absolutely not. Your idea for this thesis is worth pursuing.

Remember your contribution adds to the principle "one-thesis-attempts-to-improve-upon-another". As a researcher my image I have attached below might hopefully make that point clearer

I have a large research collection of materials about ransomware, so do ask if there is a particular point you seek clarification.

Lastly, I saw you intended to use Scalpel. That reminded me of a statement in the book - The Art of Memory Forensics - Detecting Malware and Threats in Windows, Linux, and Mac Memory (2014). Just in case you haven't read that book…

Occasionally, people still attempt to reconstruct a file from a memory sample using traditional file carving tools, such as Scalpel (https://github.com/sleuthkit/scalpel). In most instances, they attempt to run a carving tool directly against a memory sample. These tools linearly scan the data, looking for specific signatures associated with well known file formats. Unfortunately, most of these tools assume the file data is contiguous and that the media being analyzed contains a whole copy of the file. This is a problem when dealing with RAM because the data stored in physical memory is inherently fragmented, and only parts of a file may actually be loaded into memory. As a result, except for files smaller than a page of memory, you are probably not going to extract the data you expect.

Alternatively, it is possible to use a plugin like memdump to extract the virtual address space of a particular process, and scan it using a linear file-carving tool. Although this can help address the issues with non-contiguous data, you still may lose important context associated with non-resident memory pages.

Thanks and yes, give me more information.

That is not a premise, it is an assumption (and a "bad" one while we are at it).

The "right precautions" are EITHER
1) put in place BEFORE any ransomware attack is possible
OR
2) put in place AFTER a ransomware is detected BUT BEFORE defragmentation (or ANY OTHER filesystem/disk intensive activity) takes place

The problem with #2 is that a lot of time may pass between the ransomware starting encrypting all your documents and it being detected, the whole point of these ransomwares is that normally they are detected with some delay (when they finish encrypting and ask for the ransom) so if there is actually anything automated in the background or - like the example I suggested - a "huge" Photoshop session running, there will be a lot of damage done.

Besides, a number of the known "remedies" only work if you can image the memory and extract the decryption keys from it, whilst the only "really quick" way to stop a defrag, or the creation of temp files, etc. is that of "pulling the plug".

It is a hard decision to make, keep the system powered on, capture the memory and hope that a decryption tool exists or will come out or cut the power thus minimizing disk writes potentially destroying the original data (deleted but still - partially - recoverable)?

Before I forget, another variable, how does disk occupation influence the recovery?
I mean, is recovering files from a - say - 95% filled filesystem (5% free space) the same as recovering from a 25% filled system (75% free space)?

How would the number of "encryptable" files influence the behaviour?
I mean, if you have a storage disk with all .doc and .docx files, will it behave differently from a "normal" system disk with thousands of files that the ransomware won't touch?

I know that it seems like I am putting before you a lot of difficulties, but rest assured that it is only to help you consider as much as possible the different aspects of the matter before you take a path that you may later regret having taken.

Ok, I understand.
Thanks