The abstract is highly readable. I don't have time to read it now, but the strategy sounds amazing!
The strategy is that malware should imitate user behavior to throw AVs of their scent. The context in which it does this is with system calls as those happened to be monitored a lot by malware detection software.
So the big idea is "simulate user keypresses and mouse events", and it works if the user answers "yes" to the prompt "Program X wants to control other programs on this computer".
To be fair, Steam games request that permission, so users may be trained to accept it.
It shows a new dimension of attack vectors: Instead of exploiting vulnerabilities of a program (e.g. Buffer Overflow), the design of a user interface is exploited for reaching an arbitrary code execution as trusted system user.
Pretending to be a user is a good way around some anti cheat systems as well.
The computer game FIFA has an online marketplace where you can buy and sell players, and a lot of people write Chrome extensions (or Puppeteer bots) to "script" hotkeys or create sniping bots, but since EA track you constantly, they can figure it out eventually. Instead, I wrote some code to control the mouse and keyboard with cliclick (https://github.com/BlueM/cliclick), move the pointer around naturally, etc. and you can leave it running for hours without incident. https://pyautogui.readthedocs.io/en/latest/ is another approach to doing this for any Pythonistas in the house.
Yeah this is highly prevalent in the game botting industry. A lot of games these days have detection mechanisms if you access memory directly and change anything, or hook their functions. A friend of mine tried to drag me into game botting/farming before, and the supply chain is extremely well developed and professional, I was really surprised.
That being said, I've never written a complete game automation script before because it's a serious pain, it's essentially a super long series of rule based clicking. Is this the same case for your script? Or is there some easier trick? In China you can purchase game automations written by authors through a platform on a weekly subscription basis. It's technically illegal and you often hear stories of police busting some workshop whose been making millions of rmb a year off of them
Is this the same case for your script? Or is there some easier trick?
FIFA is a simplistic game at the trading level, so the answer is yes, it's lots of rule based clicking (based on things that do or don't appear on screen) but there's little nuance required. The main mechanism is just searching for underpriced cards over and over and buying them before someone else does.
I only do it for fun, I barely play the game, it's more a "because I can" side hobby to learn and play with technologies I want to try out.
The paper doesn’t mention how an elevated token was acquired. You cannot run bcdedit without privileges. Not all users will have privileges to do this.
Yeah this "technique" is a case of being on the other side of this airtight hatchway[1]. If you had the privilege to pull this off, you also can install a kernel rootkit that does the same thing. This technique is probably very easy to detect by antivirus, as it involves several weird operations.
The mentioned technique leads to an arbitrary code execution as trusted system user. The Windows Explorer process executes the malicious actions instead of the malware process. By default actions of this trusted system process will NOT be blocked or classified as malware.
Unfortunately, this method can avoid AMSI by using CMD commands. The infection part related to communication with the C&C server could be detected by AMSI if the attacker would use PowerShell or Windows Script Host, but the author uses Python.
All of this is interesting and can be dangerous by using offline ransomware (no C&C server). But in practice when the attacker wants to use C&C server then another scripting engine has to be used. If the attacker can install Python on the target machine then the Python scripts will be probably as dangerous as Phantom Malware.
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)
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.
This paper presents the way how current Anti-virus programs can be fooled by mimicked user behavior in detail. This is so impressive since this attack exploits the system's vulnerability that was not considered as a weakness before :)
17 comments
[ 2.6 ms ] story [ 43.6 ms ] threadThe strategy is that malware should imitate user behavior to throw AVs of their scent. The context in which it does this is with system calls as those happened to be monitored a lot by malware detection software.
To be fair, Steam games request that permission, so users may be trained to accept it.
25 pages of academic english are hard to read :)
The computer game FIFA has an online marketplace where you can buy and sell players, and a lot of people write Chrome extensions (or Puppeteer bots) to "script" hotkeys or create sniping bots, but since EA track you constantly, they can figure it out eventually. Instead, I wrote some code to control the mouse and keyboard with cliclick (https://github.com/BlueM/cliclick), move the pointer around naturally, etc. and you can leave it running for hours without incident. https://pyautogui.readthedocs.io/en/latest/ is another approach to doing this for any Pythonistas in the house.
That being said, I've never written a complete game automation script before because it's a serious pain, it's essentially a super long series of rule based clicking. Is this the same case for your script? Or is there some easier trick? In China you can purchase game automations written by authors through a platform on a weekly subscription basis. It's technically illegal and you often hear stories of police busting some workshop whose been making millions of rmb a year off of them
FIFA is a simplistic game at the trading level, so the answer is yes, it's lots of rule based clicking (based on things that do or don't appear on screen) but there's little nuance required. The main mechanism is just searching for underpriced cards over and over and buying them before someone else does.
I only do it for fun, I barely play the game, it's more a "because I can" side hobby to learn and play with technologies I want to try out.
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
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)
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...
This is correct!