- Jan 8, 2017
- 1,318
The AVCrypt Ransomware Tries To Uninstall Your AV Software
- Thread starter Faybert
- Start date
I don't know for sure but I would think trying to uninstall windows defender would not be a good idea for them to do.
- Feb 24, 2017
- 1,661
considering you can disable WD with Group Policy or by stopping a service or two, it really isn't.
- Aug 17, 2014
- 10,168
- May 3, 2013
- 82
Windows Defender already has self-defence.
Once malware has infected the machine and has also gained administrative privileges, it's already game over. Malware with standard rights is not going to be able to disable Windows Defender, however of course once it's acquired administrative privileges, it will be able to do so.
This was how Windows was designed to work.
Once malware has infected the machine and has also gained administrative privileges, it's already game over. Malware with standard rights is not going to be able to disable Windows Defender, however of course once it's acquired administrative privileges, it will be able to do so.
This was how Windows was designed to work.
I will have to go back and look at the link because I thought it was kinda vague as to the infection method.
- Jul 27, 2015
- 5,459
- May 26, 2014
- 1,339
Windows Defender runs at "System protected process" level, it is actually better than many other solutions self defense implementations.
I am little sceptical, does this kind of command really deletes a System Protected Process?
I know that Windows Defender can be easily disabled using Group Policy (it is by design), but the rest (delete the files) I am not so sure.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/dn313124(v=vs.85).aspx?f=255&MSPPError=-2147217396
I am little sceptical, does this kind of command really deletes a System Protected Process?
I know that Windows Defender can be easily disabled using Group Policy (it is by design), but the rest (delete the files) I am not so sure.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/dn313124(v=vs.85).aspx?f=255&MSPPError=-2147217396
Last edited:
Most modern AV comes with self-protection to prevent itself from being modified
February 2018 – Opcode
To find the right part to read relevant, use the Find Tool and enter "We’re going to take a look at how the process protection mechanism which is built-into Windows".
That bit you will find there is on the Windows process protection mechanism which is internal, you may find it interesting since you mentioned it here.
@silversurfer kindly provided me with a sample for the AVCrypt ransomware variant and I took a look at it earlier, however I've only performed some static reverse engineering through disassembly.
When the sample is first started, here's some of the things it may attempt to do
1. Attempt to obtain SeDebugPrivilege and SeShutdownPrivilege
2. Mutex creation
3. Anti-debugging is accomplished via IsDebuggerPresent. The IsDebuggrPresent Win32 API routine works internally by checking the Process Environment Block IsBeingDebugged field
4. Attempts to delete a registry key: HKEY_LOCAL_MACHINE\\Software\\Policies\\Microsoft\\Windows\\System\\DisableCMD
5. Attempts to delete a registry key: HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools
6. Attempts to disable some security software
7. Registry modification: HKEY_LOCAL_MACHINE\\HKEY_CURRENT_USER\\Software\\Microsoft\\Internet Explorer\\Download for the CheckExeSignatures
9. Disables User Account Control and SmartScreen (quick glance it would appear this is the case)
10. Changes the wallpaper on the Desktop (quick glance it would appear this is the case)
The articles from others will probably cover more on what the sample does/how it works, it does more than the above and some operations involve usage of cmd, etc. The sample isn't limited to the above.
I was mainly interested in how the encryption routine worked so I located it in the disassembly, here's some insight into it.
1. CreateFileW
2. CryptAcquireContextW
3. CryptCreateHash
4. CryptHashData
5. CryptDeriveKey
6. ReadFile
7. CryptEncrypt
8. WriteFile
9. CloseHandle
The CreateFileW (KERNEL32 -> KERNELBASE) call is required to get a handle on the targeted file for encryption, and since it's CreateFileW, the buffer is unicode-encoded (wide-string). Without acquiring the file handle, the ransomware will be unable to read/write from and to the file. It will also need to have the necessary privileges to acquire the file handle with the desired handle access rights needed for its read/write operations.
The ReadFile (KERNEL32 -> KERNELBASE) call is required to read the contents of the file into memory. This is done so the original contents now stored in-memory can be encrypted, and then the then-encrypted buffer will replace the original contents with the file write operation.
The WriiteFile (KERNEL32 -> KERNELBASE) call is required to overwrite the original file contents with the encrypted copy.
The CloseHandle call is to close the opened file handle now the operation with that file is over.
Regarding enumeration of files on the system, it relies on FindFirstFileExW and FindNextFileExW Win32 API routines to enumerate through directories recursively and locate files which are a target for the encryption procedure.
-----
The sample will rely on the MoveFileEx Win32 API routine to try and automatically delete itself on the next reboot. This works depending on the parameter data given to the routine, and the routine internally works by using the registry.
For the record, disabling of Windows Defender isn't only via one technique. It attempts to attack multiple areas, e.g. registry configuration area for it as well.
In other words it is your average home user malware and will likely be blocked by your AV.
When the sample is first started, here's some of the things it may attempt to do
1. Attempt to obtain SeDebugPrivilege and SeShutdownPrivilege
2. Mutex creation
3. Anti-debugging is accomplished via IsDebuggerPresent. The IsDebuggrPresent Win32 API routine works internally by checking the Process Environment Block IsBeingDebugged field
4. Attempts to delete a registry key: HKEY_LOCAL_MACHINE\\Software\\Policies\\Microsoft\\Windows\\System\\DisableCMD
5. Attempts to delete a registry key: HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools
6. Attempts to disable some security software
7. Registry modification: HKEY_LOCAL_MACHINE\\HKEY_CURRENT_USER\\Software\\Microsoft\\Internet Explorer\\Download for the CheckExeSignatures
9. Disables User Account Control and SmartScreen (quick glance it would appear this is the case)
10. Changes the wallpaper on the Desktop (quick glance it would appear this is the case)
The articles from others will probably cover more on what the sample does/how it works, it does more than the above and some operations involve usage of cmd, etc. The sample isn't limited to the above.
I was mainly interested in how the encryption routine worked so I located it in the disassembly, here's some insight into it.
1. CreateFileW
2. CryptAcquireContextW
3. CryptCreateHash
4. CryptHashData
5. CryptDeriveKey
6. ReadFile
7. CryptEncrypt
8. WriteFile
9. CloseHandle
The CreateFileW (KERNEL32 -> KERNELBASE) call is required to get a handle on the targeted file for encryption, and since it's CreateFileW, the buffer is unicode-encoded (wide-string). Without acquiring the file handle, the ransomware will be unable to read/write from and to the file. It will also need to have the necessary privileges to acquire the file handle with the desired handle access rights needed for its read/write operations.
The ReadFile (KERNEL32 -> KERNELBASE) call is required to read the contents of the file into memory. This is done so the original contents now stored in-memory can be encrypted, and then the then-encrypted buffer will replace the original contents with the file write operation.
The WriiteFile (KERNEL32 -> KERNELBASE) call is required to overwrite the original file contents with the encrypted copy.
The CloseHandle call is to close the opened file handle now the operation with that file is over.
Regarding enumeration of files on the system, it relies on FindFirstFileExW and FindNextFileExW Win32 API routines to enumerate through directories recursively and locate files which are a target for the encryption procedure.
-----
The sample will rely on the MoveFileEx Win32 API routine to try and automatically delete itself on the next reboot. This works depending on the parameter data given to the routine, and the routine internally works by using the registry.
For the record, disabling of Windows Defender isn't only via one technique. It attempts to attack multiple areas, e.g. registry configuration area for it as well.
In other words it is your average home user malware and will likely be blocked by your AV.
Similar threads
