http://blog.ensilo.com/moker-a-new-apt-discovered-within-a-sensitive-network There is also a technical analysis here - http://breakingmalware.com/malware/moker-part-1-dissecting-a-new-apt-under-the-microscope/
In English 'Moker' means 'big' or 'large', in Dutch it's a synonym for sledge hammer or maul. Anyone here who knows the term 'Moker' from another language?
Sounds like the usual "evasion" techniques against virtualization BS to me. Although what damage it can do with Remote Desktop would be interesting... And double-clicking the damn thing of course... Unless proven otherwise, another dumbed down FUD.
It's network based malware. So anyone running on a stand alone PC or home network doesn't have to worry. RDP disabled by default on those systems. Has all the usual elements discussed previously in other Wilder's threads. I am sure Eset's IDS would catch it. Also main process it injects is explorer.exe which I have already protected against memory injection.
@Baserk In danish - Mukkert - (from Dutch: fat girl) a big and heavy squered hammer. -En mukkert ((Hollandsk/Nederlandsk): mokke, tyk pige) er en stor og tung firkantet hammer-
Yes I've done some reading. Interesting was that it used "process hollowing" and also "Elevation of privileges". The first would be stopped by HIPS (process modification), the second could be stopped by HIPS watching for file creation inside the C:\Windows\system32\ folder.
Notice that it did not use an exploit to elevate privileges. It actually used a Windows process, sysprep, to do it! There is a Windows design vulnerability which enables loading unauthorized DLLs by authorized applications. This vulnerability is found in the way Windows loads DLLs upon request. When an application loads a DLL by its name, Windows first looks through the application’s current folder, and then proceeds to search at system directories (and other paths). In order to avoid a predicted chaos using this technique, some DLLs are always loaded from the system directory regardless of any other same named DLLs found in its own path. Monitoring sysprep shows it loading one DLL which does not follow this restriction: ActionQueue.dll. Also, my testing of Eset's HIPS monitoring rule has shown that it will detect any startup of a process regardless of the file extension or lack of it in this instance i.e. a xxxx. file located in %AppData% directory or sub-directory.