Block mapped page writer write

NTFSD
1

Hey , a standard FLT_PREOP_COMPLETE isn't sufficient here - as the mapped page writer will continue to initiate writes (the pfn remains modified)

I attempted to set Iopb.Parameters.Write.Length to 0 , whilst in procmon I could see an IRP_MJ_WRITE from the system process with length 0 the file still changed

obviously the aim here is to prevent the modification , so I thought about reading the pre write content and swapping buffers whilst letting the write proceed , but would appreciate an advice regarding what would best practice in this situation

2

Once the data is dirty that's MPW will keep on trying (ISTR that it might eventually give up in disgust and flag a warning).

Let's back up.. What are you trying to achieve ? (this feels like a "Sticking Wings on a Pig" moment).

  • What is the project requirement?
  • Where are you trying to "prevent modification"?
  • What attritional damage are you prepared to put up with?
3

I'm working on an "anti ransomware" filter , In general once I detect X number of files have been encrypted I kill the malicious process , but since with mapped files the write is asynchronous there's a chance I'd see mapped page writer writes AFTER the process has already terminated , in that case , I can't prevent those writes by killing the process , the writes have already been "scheduled" as the PTEs are dirty
to deal with that ,during (pre) paging write filtering - if a process considered as malicious owned a R/W section object for the file in question (I keep that info beyond the process's lifetime) , I have to prevent the write somehow

4

Thanks..

It's not just mapped files of course. the lazy writer will be busy trying to write back any cached writes that you ransomware managed to get done before you killed it.

It seems like BSODing the machine would be a reasonable option - then no more harm can be done and when you come back you'll know about the bad actor. I know I'd sooner see my machine reboot and come back in safe mode with a warning that have even some of my data corrupted.

But if you want to struggle on you can just lie. If a file is suspect just successfully complete the writes (with the length asked for). The Mm will then dutifully mark the page as clean.

You should of course deny access to this file from now on

  • It has potentially bad data cached
  • Depending on what the application does they may see the bad data (in cache) or the correct data (on disk). You could mitigate this to a degree by trying to get the filesystem to (flush and) purge the cache, indeed that might be a good way to hurry things up.
1 Like
5

BSODing sounds like a good option : )

by just successfully completing the writes the file will be modified (I assume I misunderstand you here) , surely I need to manipulate the write somehow ? as mentioned I tried to "lie" by setting the Length to 0 and completing the write but file still ended up modified : (

6

"lie" by setting the Length to 0 and completing the write but file still ended up modified

Thats not a 'lie' per se, you are saying "I successfully wrote zero bytes" which is truthful but (as you discovered) non productive

Data->Iosb.Status = STATUS_SUCCESS;
Data->Iosb.Information = Data->Iopb->Parameters.Write.Length;
return FLT_PREOP_COMPLETE

Is an outright fib "I sucessfully wrote all that data, have a nice day" but should do the job.

Like I say at this stage you are now facing major cache coherency issues which will eventually cause applications to fail (and potentially the machine to crash).

3 Likes
7

thanks , just for experimenting , CcCoherencyFlushAndPurgeCache is the function to work with ?

8

No, you are not allowed to call that unless you are the filesystem and things will go very badly wrong if you do.

Since about windows 8 there has been a minor function you can add to IRP_MJ_FLUSH_BUFFERS. Just send that down (but dont do it in the context of your paging write because that may/will deadlock - post it if needs be)

1 Like
9

cool , I read it would require an isolation filter which is beyond the scope of the project : (
In theory i could also provide the user with a dedicated folder of backups to encrypted files , and let the encryptions happen , but since ransomwares tend to encrypt thousands of files I'm not sure if that would be better than just KeBugCheckEx ?

10

I know little about this stuff but it strikes me that if you can take a full memory dump of the rogue process (all memory is better) a good forensic specialist would be able to extra the encrypting key and IP addresses being used.

As a certain large software-and-cloud-service company is painfully aware, if you don't use an HSM (and ransomware by it's very nature cannot ) private keys have a habit of turning up in memory dumps of crashed machine.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.