Hacker Newsnew | past | comments | ask | show | jobs | submit | PhantomHacker's commentslogin

I want to sum up the most important facts:

I. An additional desktop will be created. The Windows Explorer (WE) will be opened on this desktop. Afterwards, the command will be inserted into its input box and confirmed for execution by sending corresponding Windows Messages. The victim will NOT see a CMD or any up popping window due to all these actions do not happened on the victim's current desktop.

II. Phantom Malware splits up its malicious actions into a sequence of non-malicious SendMessage WinAPI calls. (see VI. ANALYSIS → A. FAILURE OF ANTI-VIRUS SOFTWARE).

III. The WE is a preinstalled file manager and a fundamental part of the desktop environment of Windows, which makes this process trustworthy. Due to inserting and confirming a malicious command in the WE's input box, this trusted system process is manipulated to execute the command. Antivirus software will not block actions of a trusted system because it is considered bad practice. Besides, the operating system including modules of anti-virus software, such as behavior blockers, are fooled into perceiving that the user themselves has done the command insertion and its confirmation. In other words, it mistakenly looks like the execution of the malicious command has a legit basis with the user having intended the execution. (quoted form IX. CONCLUSION)


> An additional desktop will be created.

For those not familiar with Windows internals here's the documentation for the desktop[1] object.

In particular note the following:

"Window messages can be sent only between processes that are on the same desktop. In addition, the hook procedure of a process running on a particular desktop can only receive messages intended for windows created in the same desktop.

...

During the user's session, the system switches to the Winlogon desktop when the user presses the CTRL+ALT+DEL key sequence, or when the User Account Control (UAC) dialog box is open.

The Winlogon desktop's security descriptor allows access to a very restricted set of accounts, including the LocalSystem account. Applications generally do not carry any of these accounts' SIDs in their tokens and therefore cannot access the Winlogon desktop or switch to a different desktop while the Winlogon desktop is active."

Thus the exploit program shouldn't be able to press "Yes" on the UAC dialog. It seems the paper mentions this as well, but I didn't have time to study the rest of the paper to see how they overcome this to do interesting stuff.

[1]: https://docs.microsoft.com/en-us/windows/win32/winstation/de...


> Thus the exploit program shouldn't be able to press "Yes" on the UAC dialog.

This is correct!


Conceal Malicious Actions From Malware Detection Techniques by Imitating User Activity


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: