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.
