Don't worry mate, I haven't noticed that Lol
I got some stuff wrong on encryption too.
We live and learn!!
The DLL used by rundll32.exe will also create a file called cscc.dat in the Windows directory ("\\??\\Windows\\cscc.dat"). It will write to it to store executable code once again.
Another file will be created in the Windows directory straight afterwards called dispci.exe. Once again, the bytes are written to it from within the DLL code. The executable is ran once the bytes have been written to it.
You can monitor NtCreateNamedPipeFile, NtFsControlFile, NtDeviceIoControlFile and NtCreateUserProcess/NtResumeThread with break-points to intercept when analysing. You'll be able to keep track of the scheduled task operations with the NtCreateUserProcess break-point because it will use cmd.exe for it (which needs to be spawned) -> check the command line. NtDeviceIoControlFile because the sample uses IOCTL to communicate with a kernel-mode component used for encryption of partitions. Just make sure you are monitoring for other spawns (e.g. rundll32.exe -> child of the launcher).
The kernel-mode part explains why the DLL has code for searching for fixed drives; it will encrypt the partitions but is only interested if the drives are fixed. I hope this is correct info.
There is also functionality for hijacking the Master Boot Record it seems...
It is a pretty nasty threat.