[Iradicator]

Hi,

I was running a POC for doppelganger injection method which create a new NTFS transaction, and inside this transaction create a dummy file to store the malicious payload
and being undetected by AV unless the transaction is committed (see code here https://github.com/Spajed/processrefund)

However, on the setup where my POC was running, I also had freshly installer minifilter driver that assigned callback on event preCleanup from which the method
FltGetFileNameInformation is called, and sometimes return the above error if the POC starts right after the driver was installed.

Perhaps anyone else encounter this error and can explain it more thoroughly.
I guess that the transaction was already over at the preCleanup phase (before the file was closed) but the file is still , but why does it prevent me from getting the file name ?

thanks !

[Brock]

Could be due to several reasons. Without seeing a line of code we'd be playing guessing games, wouldn't we? What does your call to FltGetFileNameInformation() look like, mainly the "nameoptions"?

[Iradicator]

So, the first parameter comes from the callback (PFLT_CALLBACK_DATA Data) and the third parameter is defined just before the function call ( PFLT_FILE_NAME_INFORMATION fileInfo = NULL;), nothing interesting here...

As for the nameOption, it's set to `FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT`.
I guess that FLT_FILE_NAME_OPENED has nothing to do with the transaction not being active.
However, for FLT_FILE_NAME_QUERY_DEFAULT it's mentioned in the documentation that "If it is not currently safe to query the file system for the file name, FltGetFileNameInformation does nothing." - so it might be causing the problem.

My goal is to understand what make the file "not safe to be queried" ... Perhaps since the doppelganger uses the transaction in and neither rollback not commit it (so it'll be unnoticeable to AVs) I get this error. There must be some kind of race when the file is closed and the transaction still remains.

Maybe you can elaborate on this issue with this new information .


thanks !

[Iradicator]

One more point I forgot to mention,

There's a slight chance that in the scenario where the problem has occurred, the rollback phase was skipped so the file with transaction was closed with pending transaction.

[Brock]

There's a slight chance that in the scenario where the problem has occurred, the rollback phase was skipped so the file with transaction was closed with pending transaction.

KTM should automatically roll the transaction back upon the last handle to the tx being closed before any commit action, according to the remarks section of CreateTransaction() API

Use the CloseHandle function to close the transaction handle. If the last transaction handle is closed before a client calls the CommitTransaction function with the transaction handle, then KTM rolls back the transaction.

You might use ktmutil.exe to see if it's still active however. MSDN Win32 API remarks aren't always correct and can be misleading.

[Iradicator]

Hi Brock and thanks for your reply,

So it turns out the transaction was actually rolled back already, while I close the transacted file.

Perhaps do you know of an option to detect that the file is transaction based file (created using CreateFileTransacted method in user-space) and not regular file from preCleanup stage where i got the params

Code: Select all

PFLT_CALLBACK_DATA Data

and

Code: Select all

PCFLT_RELATED_OBJECTS FltObjects

I simply wish to ignore those files completely since they may have not active transaction.


thanks,

[Brock]

Please see here:

https://github.com/microsoft/Windows-dr ... r/avscan.c

it shows how to detect and optionally handle transacted files

Best regards

[Iradicator]

Thanks Brock, this link really helped clarifying the transacted file life cycle.

[Brock]

No problem. Glad it is useful to you. I believe it’s a pretty decent example