I am assuming that the malware is already on your disk (not all malware hits the disk!). So keep that in mind when following this answer. If this is not the case, please provide more information.
On Windows many files that are in use and therefore cannot be deleted can be dealt in one of two ways:
- rename the file (the
ren command on the command prompt should help)
- failing 1., a tool such as MoveFile can be used to tell the session manager (
smss.exe) to move the file early during a boot
By renaming the file you can oftentimes ensure that next time an attempt is made to load the malware, it will fail. However, if there is some kind of dropper involved, attempting to download this malware time and time again, this may fail.
In such a case you can attempt a variation on the two above methods. You can create a directory of the same name as the malware file or conversely a file if this concerns a directory. So given the path
C:\Users\NMolinero\AppData\Local\Temp\csrss\scheduled.exe you have two options:
- rename the
C:\Users\NMolinero\AppData\Local\Temp\csrss to something else and then create a file with that same full path in its stead.
- rename the file
C:\Users\NMolinero\AppData\Local\Temp\csrss\scheduled.exe and create a directory with that exact same full path in its stead (yes, a folder with the
.exe file extension).
For the MoveFile method I am mentioning above, you may have to create a folder of some arbitrary name and use MoveFile to rename it to
C:\Users\NMolinero\AppData\Local\Temp\csrss\scheduled.exe respectively. That is, depending on the exact behavior you observe you may have to deviate slightly from the "overall" methods I am outlining.
In theory all of this can still fail. We can reasonably assume that the file paths you gave are the actual file paths of the malware entities, since they appear in the context of a command being executed. In general it would also be possible for a malware to camouflage itself by using a path or file name that is invalid in terms of the Win32 subsystem (see here). In this case you would have to use one of the alternative path notations (explained in the linked article) in order to escape the path conversion and "vetting" at the Win32 subsystem layer.
Failing all of the above you may want to pick up a recent live CD (Linux Mint, Ubuntu, whatever ...) with support for the NTFS file system (I have to assume once again here), in order to make the above mentioned modifications while your Windows system (and therefore the malware) lies dormant.
After you're done with these steps you should be able to extract the malware and perform whatever static analysis you want with whichever tool you prefer.
If MoveFile fails or you cannot use it for whatever reason, you could always attempt to schedule the move operation via the
PendingFileRenameOperations registry value. But frankly if the malware prevents you from using something like MoveFile or the registry editor you may want to use the "offline" method I described as last resort.