A forum for reverse engineering, OS internals and malware analysis 

 #33047  by Iradicator
 Thu Jul 04, 2019 9:18 pm

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 !
 #33052  by Iradicator
 Sat Jul 06, 2019 1:05 pm
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 !
 #33054  by Brock
 Sun Jul 07, 2019 6:22 pm
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.
 #33056  by Iradicator
 Sun Jul 07, 2019 7:06 pm
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
Code: Select all
I simply wish to ignore those files completely since they may have not active transaction.