xor_dhillon

Level 1
There are few things I had ideas on, Could you please tell me which are bad ideas and which are good to detecting/helping prevent malware? I am kind of new to this so any help is appreciated :).

1. If a file has inline hooks and attempts to do some sort of Remote Thread creation or DLL Injection, is it safe to label it as malware?

2. Is it okay to prevent creation of remote non privileged threads? Of course not system threads... because that would lead to bsod.

3. What is the difference between PFLT_PRE_OPERATION_CALLBACK and using IRP codes like IRP_MJ_CREATE to notify on file movement.

4. Is there any use of creating a keyboard and mouse driver filter?

5. Is ObRegisterCallbacks good enough for self protection ? (I am not talking about registry and etc.)

6. Also is it a bad idea to maybe upload files (of course with user consent and if it is not detected as malware) dropped as a subprocess of word/pdf/ppt etc.. after checking it against a database of goodware?
 
  • Like
Reactions: frogboy and AtlBo
D

Deleted member 65228

1. If a file has inline hooks and attempts to do some sort of Remote Thread creation or DLL Injection, is it safe to label it as malware?
I don't understand this question that well, but here's some notes which might help you out.

1. If a running program is locally hooking it's own routines, if it's targeting a routine like LdrLoadDll, LdrInitializeThunk or KiUserApcDispatcher, then it's likely trying to prevent interception of it's process. This would indeed be suspicious because such is not common in genuine software; most genuine normal software developers aren't even aware of what those routines are.

2. If a running program is trying to create a remote thread in another process, you can flag this internally for future reference, or take action at that very moment. However, be very careful how you tread. Some genuine software will create a remote thread in another process; you should depend on other characteristics/logged behavior to assist you. You can also develop a memory tracking feature (something which I once did in this situation) to identify if the remote thread is passing an address for the parameter of the newly starting up thread which the program allocated/wrote to before the thread creation attempt, and you can also identify the address for the thread to start executing at (e.g. commonly for DLL injection this will be LoadLibraryA/W however shell-code injection will be targeting the address of where it's shell-code is located at within the address space of the process being targeted of course).

3. There are many ways to inject code, some are a lot stealthier than typical remote thread creation. One quick example would be via Asynchronous Procedure Calls, or thread hijacking. You also have remote patching of memory which won't require a trigger like a thread spawn/hijack to get the attacker's shell-code running.

See this thread: Malware Analysis - Code injection identification [Malware Analysis]

3. What is the difference between PFLT_PRE_OPERATION_CALLBACK and using IRP codes like IRP_MJ_CREATE to notify on file movement.
When you intercept a file-system operation with FltRegisterFilter, you get given various data in pointer structures passed to the pre-callback routine.

Code:
typedef FLT_PREOP_CALLBACK_STATUS ( *PFLT_PRE_OPERATION_CALLBACK)(
  _Inout_ PFLT_CALLBACK_DATA    Data,
  _In_    PCFLT_RELATED_OBJECTS FltObjects,
  _Out_   PVOID                 *CompletionContext
);
Look at the first parameter, Data (data-type of PFLT_CALLBACK_DATA).

Code:
typedef struct _FLT_CALLBACK_DATA {
  FLT_CALLBACK_DATA_FLAGS       Flags;
  const PETHREAD                Thread;
  const PFLT_IO_PARAMETER_BLOCK Iopb;
  IO_STATUS_BLOCK               IoStatus;
  struct _FLT_TAG_DATA_BUFFER  *TagData;
  union {
   struct {
     LIST_ENTRY QueueLinks;
     PVOID      QueueContext[2];
   };
   PVOID  FilterContext[4];
  };
  KPROCESSOR_MODE               RequestorMode;
} FLT_CALLBACK_DATA, *PFLT_CALLBACK_DATA;
The third entry in this structure will be of interest to you to determine which sort of operation is going to occur. The Iopb entry (or field) which has a data-type of PFLT_IO_PARAMETER_BLOCK stores such data within it.

Code:
typedef struct _FLT_IO_PARAMETER_BLOCK {
  ULONG          IrpFlags;
  UCHAR          MajorFunction;
  UCHAR          MinorFunction;
  UCHAR          OperationFlags;
  UCHAR          Reserved;
  PFILE_OBJECT   TargetFileObject;
  PFLT_INSTANCE  TargetInstance;
  FLT_PARAMETERS Parameters;
} FLT_IO_PARAMETER_BLOCK, *PFLT_IO_PARAMETER_BLOCK;
You can do a comparison with the MajorFunction entry in the pointer-structure which will be accessible to you.

Please see: FLT_IO_PARAMETER_BLOCK structure (Windows Drivers)

5. Is ObRegisterCallbacks good enough for self protection ? (I am not talking about registry and etc.)
ObRegisterCallbacks is good for preventing a handle being opened/duplicated for your protected Anti-Virus processes (it also supports thread protection) however there's many other attack vectors. ObRegisterCallbacks supports interception of handle creation/duplication for Desktop handles as well now which may be of interest to you.

You can start by blocking window requests to your GUI process for WM_CLOSE and WM_DESTROY. You can also close opened handles under system processes (e.g. csrss.exe on earlier versions of Windows, lsass.exe on recent versions, even svchost.exe). The windows can be attacked via EWM injection attacks as well, so you'll need to keep your eye out for this one.

Say on case someone manages to get a handle/find another creative way to inject a DLL (which is easier than shell-code), you can detect unwanted DLL loads in your own process via PsSetLoadProcessNotifyRoutineEx. You can use this routine for real-time scanning of modules as processes are loaded them, too.

You need to make sure your product is stable overall, otherwise self-protection mitigations are useless. For example, if you have a buggy scanning engine, a potential bypass would be to cause your software to crash (potentially invoking a BSOD as well) just because it read a document during scanning which contains characters it doesn't like, or has a buffer too large which was ignored because of bad checking.

Whatever you decide to do in the end, make sure the self-protection can be disabled and do not patch the Windows Kernel.

6. Also is it a bad idea to maybe upload files (of course with user consent and if it is not detected as malware) dropped as a subprocess of word/pdf/ppt etc.. after checking it against a database of goodware?
Ask on the installer if cloud sharing is allowed, and have a good privacy policy which must be accepted before installation. Don't intentionally make the privacy policy longer than it needs to be, and make it very easy for an average person to see what sort of data will/won't be transmitted over the network for functionality of your product - that would be ethical.

Also make sure that anything you upload is cleaned out otherwise if your network becomes breached, people's personal documents will be vulnerable. Even if they were uploaded months ago and the person is no longer using your product.

-------

I recommend you take a few months from working on the code-base of your product specifically and dedicate it to experimental testing and education on both kernel-mode and user-mode development, and use it as an opportunity to expand on Windows Internals. Then go back to it after the few months break and implement the file-system interception and self-protection features, and fine-tune the behavioural analysis you appear to be working on.

Test, test, test and test. Never stop testing. Don't release anything until it's been properly tested, doesn't behave unethically and ensure it works well - test on different systems under different circumstances. Intentionally go out of your way to break/ruin it and then improve its stability/security, then repeat this process all over again. First impressions count, if you mess up the first impression or smash the ice then you'll be over before you started.

Don't expect to make good revenue at the start either. There are vendors who've been doing everything you seem to want to do since Windows Vista/7, it will take you a long time to catch up to them with the same level of security and stability without impacting performance too much. The human mind is a powerful thing, if you put your mind to it and work hard then you will hopefully achieve your goals.

Try new things out, test them effectively, remove something if it turned out to be a bad idea. Sometimes a bad idea at first could develop into a spectacular idea, and vice-versa.

Good luck. ;)
 

xor_dhillon

Level 1
Thanks, @Opcode :p for clearing it up for me,
I have begun to write a file IRP I only needed it to detect file movement and thanks for clearing up my confusion o_O

For my first question, it was a question based on formgrabbers. Most formgrabbers have some sort of inline hook to PR_Write(firefox) SSL_Write(chrome) etc. So my question was If my program detects an inline hook with DLL injection capabilities, can I label this as banking malware?

And yes I am already using PsSetLoadProcessNotifyRoutine and PsSetCreateThreadNotifyRoutine and PsSetLoadImageNotifyRoutine to detect creation of any thread/image/process as well as protect my own process. And I thought you cannot really patch the windows kernel anymore because of KPP?