Originally posted by Thiesen:

Under WIndows this doesn't happens since NOTHING is sandboxed under Windows...

The malware was copied to C:\WINDOWS\system32\lssas.exe, compromising the lssase.exe service in both Linux and Windows.

None of the files that appeared to be dropped by the malware in the Windows environment were also dropped in the Linux environment, this suggests that the malware had not been successful at compromising the Linux system. None of the relevant registry API calls that were made in Windows were successful in Wine, this indicates that the malware had failed to make key registry changes when running in Linux.
...
The evidence collected during analysis suggests that the malware failed to compromise the Linux system running Wine. In Linux, the second process failed to initialize and the main process crashed during execution.
...
Analysis results for the Drixed sample can be viewed in Table 7. The analysis suggests that the malware was unsuccessful in compromising a computer running Linux and the Windows compatibility software Wine, the overall results can be viewed in Table 8. The malware did not extract information from internet browsers when running in the Linux environment.
...
The malware called eight functions to delete files in the Windows but only called three in the Linux. Similar registry based API calls were made in both environments, the most significant call being found in both environments in the location Software\Microsoft\Windows\CurrentVersion\Run, this registry location was changed to allow the malware to run when the infected computer started up. When running in Zero Wine some key processes failed to start and the Sleep.exe’ process crashed. Overall it was clear that the malware was not successful at compromising the Linux computer system.
...
When the malware was run on Windows it dropped the file rasphone.pbk was dropped by the malware, the difference list that was generated by Zero Wine confirmed that this file was not dropped in the Linux environment. The malware also failed to make significant changes to the registry in Linux such as the RAS AutoDial which is located at Software\Microsoft\RAS AutoDial. The malware successfully started all of the processes in the Linux environment; however, it was unable to start any of the services that were started in the Windows environment.
...
The malware did not recreate the vital registry based API calls that were called in the Windows environment. The malware was unsuccessful at making changes to the registry to ensure that it ran on start-up. The malware also failed to make changes to the registry to edit the Internet settings. The same processes started in Windows and Linux. The network traffic was not similar in the Linux environment with no DNS requests being detected. None of the services started in Windows were also started in Linux. It is clear that overall the malware was not successful at compromising the Linux system.
...
This means that it has not achieved its function of fingerprinting the system and had not made changes to the system to ensure that it would run on start-up. The fact that the main process appears to have failed to initialize suggests further that the malware has failed to compromise the target machine. The network activity, in Windows recorded as attempting to communicate with 91.239.232.145, was also not present in the PCAP file generated in the Linux environment. Neither the Tapisrv’ nor Rasman’ service was opened in the Linux environment. Table 22 concludes that the malware was unsuccessful in all areas, meaning it has failed to run successfully.
....
The network traffic that was detected in Windows revealed multiple DNS and ICMP requests. No similar packets were detected when the malware was run in the Linux environment. Overall the malware sample was partially successful at running in the Linux environment as similarities were found in the registry based API calls.
...
However, the malware was not entirely successful as it did not generate any network traffic in the Linux environment. The network traffic from the Windows virtual machine revealed that the malware attempted a DNS request to triplexfund.com. No similar packets were captured in the PCAP file generated by Zero Wine, this suggests that the malware was not completely successful as the call home function failed.

Originally posted by Dango:

Is this related to steam removing the option to disable Steam Play for other titles option in the compatibility section?

Originally posted by ShelLuser:

OP... did you even bother to actually read the article or did you simply do like many others: stop after you read the headline (and the summary / conclusion)?

Because it's pretty obvious from these quotes that the allegid risk is actually... non-existent. Because most of the malware that got tested... actually failed to do anything.

Originally posted by Lennos:

The response I got from Steams customer service inspired no confidence and I'm sad to say indicated that support is entirely clueless on this topic, so I doubt we'll be able to get help that way.