Over the past decade, numerous cyber attacks have made headlines, each attack more serious than the previous ones: larger in scope, greater in sophistication and more advanced in data exfiltration. These attacks have been possible thanks to malware programs (e.g., Bot, Trojan and POS) that are incorporated with new and advanced stealth techniques that keep them undetected.
Although a variety of threat-detection techniques for combating such malware have been developed over the years, the attackers continue to find new and creative methods for getting around these techniques. In other words, classic prevention and detection defence techniques, such as firewall-based software, signatures and rules, antivirus software and intrusion detection systems (IDS), do not suffice in the battle against cyber attacks. While they may be able to protect against known attacks, classic defense systems are to no avail when protecting against new ones that lack a fingerprint.
Moreover, malware technologies seems to always be one step ahead of IDS, security information and event management (SIEM) technologies [1, 2], as the latter focus on the technology used by the attacker, are based on predefined rules for detecting breaches, have low flexibility to noise and have restricted visibility due to limited access to data. There is, therefore, a genuine demand for a more creative and adaptive method that will provide a last line of defense against malware.
This paper proposes a novel counter-attack method for automatically detecting malware infection at endpoints, using both offensive and defensive techniques. We leveraged the idea that each piece of malicious code has vulnerable security holes that can be utilised for detecting and preventing malicious infection of endpoints. Using controlled experiments, we investigated and analysed several types of malware programs, leading to the development of a new methodology and detection technique that provides an additional layer of defence in the fight against malware programs – even against previously unknown ones. We first focused on identifying common features and capabilities among malware programs, such as the type of information that is requested by malware programs on endpoints and the common data they require in order to continue their malicious activities. To do so, predefined scripts were injected into endpoint information to constantly look for malware vulnerabilities. We also focused on identifying the goals and objectives of malware programs, so that we could provide a comprehensive solution that would combat a wide range of malwares, including previously unknown ones. Malware goals include the exfiltration of sensitive data such as people’s credentials, passwords, documents and credit card details and the carrying out of a denial of service (DOS) attack on a specific target. Unlike other techniques, our new generation detection technique is not based on the specific attributes or behaviors of the malwares, but rather on our taking advantage of their malicious achievements at the endpoints.
In other words, our novel approach issues a counter-attack on malware based on the information that the latter derives from endpoints, and utilising the trusted communications between the malware and its C&C. First, this technique detects malware infection by modifying endpoint information to consist of a XSS string. Once this information is queried by the malware and is presented on a web page, the technique then alerts an isolated server regarding the infection. In this manner, our method – combined with classic threat-detection techniques – provides an extra layer of detection to deal with previously unknown malware.The contributions of this technique are numerous. First, it expands on and enhances existing threat detection techniques by exploiting malware vulnerabilities. Second, it reduces the serious gap between cyber defenders and cyber attackers. Third, this novel technique challenges malware developers in the defense aspect. Finally, it paves the way for a variety of generic offensive detection techniques in the future.
Related Work
There has been an extensive amount of research on malware detection techniques in general and on the vulnerabilities of malware C&C panels in particular. In the closest work to ours, Sood et al [5] used the properties and features of remote panels to detect other C&C panels and in turn more infections. Sood collected the unique property values of the malware programs’ C&C panels (Zeus, ICE IX and Citadel) using malware analysis and network forensic techniques. These values were then used to detect new C&C panels of the above-mentioned malware programs via Google dorks, C&C trackers, and network traffic analysis. However, these unique values were only collected after dynamic analysis of the malwares and a leak of their C&C panel. In contrast, our detection technique, that exploits vulnerabilities in malware C&C panels, is generic and can detect any insecure C&C panel, regardless of its unique properties or values. In addition, a dynamic analysis of the malware isn’t a prerequisite in our detection technique.
Additional studies [6, 7] found vulnerabilities in the Phase bot and ICE IX C&C panels, and showed that malware C&C panels can be taken advantage of in the war against hackers. Sood, for example, discovered a XSS vulnerability in the main login page of the ICE botnet C&C panel. In a different study [8], SQL injection (SQLI) vulnerability was detected in Dexter C&C panels. Exploiting this vulnerability can grant the attacker control of the remote administration panel of the bot. In another study, researchers at Prolexic (Akamai) [9, 10] identified vulnerable code in the Dirt Jumper Family’s (DJF) C&C that enables the configuration file to be take advantage of and downloaded using the SQLI technique. This file consists of all the account credentials needed to take over the attacker’s C&C panel. Moreover, even the notorious Zeus malware was found vulnerable [11]. A security researcher found a vulnerability, and developed a simple program to take advantage of it. His script allows users to directly upload and execute the code of their choice on the server that is running the Zeus C&C. In another work similar to ours, Grange [12] disclosed several exploits on the C&C servers of Gh0st Remote Access Trojan (Rat), PlugX and XtremeRat malware. These exploits enable the defender to take full control of malware C&C. Our work differs from Grange’s in a number of aspects. First, although our work can also be used for counter-hacking, its main purpose is to detect malware attack. Furthermore, or work uses malware vulnerabilities in order to detect their C&C panel, whereas Grange’s work uses them after malware C&C is already known. Second, these vulnerabilities are only designed for the above malware, whereas our technique is not dependent on a specific malware and can detect new, previously unknown malware. Leder et al. [13] demonstrated that proactive counter-measures are effective and necessary in the fight against real botnets. Focusing on Kraken, Storm worm and Waledac malware, their research found specific vulnerabilities that can be used to take control of malware. Dereszowski discovered a buffer overflow vulnerability and developed an exploit against the C&C server of Poison Ivy RAT that provides remote code execution [14]. Researchers at malware.lu developed a scanner tool for identifying new C&C of Poison Ivy and Terminator RAT that were used to compromise their C2 servers [15].
Table 1. Information collected by malware.
In order to develop an effective tool for detecting malware, and without harming endpoints’ applications in the organisation on the infected endpoint, we set up a new environment that models both the organisation gateway and the attackers’ malicious C&C panel. As depicted in Figure 1, this environment included the endpoint host with the PhoeniXSS tool, the C&C Server with a leaked version of a malware program’s remote administration tool, and a monitoring server. The endpoint host was used to execute incoming binary files. Each file had to be executed by a PhoeniXSS tool for a minute period (maximum) before entering the organization. During file execution, PhoeniXSS hooks all predefined API functions and adds a predefined XSS string to their returned values. In this work, malware programs were tested with a specific XSS string using the PhoeniXSS tool. During infection, the above values are sent to the malware program’s remote administration panel. Many malware web panels exhibit common values on the infected machines (e.g., computer name, user name and processor name). However, once one of these values is not validated and/or is treated incorrectly, the attacker’s web panel becomes vulnerable to a XSS attack. We used this vulnerability to create an alert on our monitoring server. Finally, the monitoring server is programmed to wait for the http/s request. Although any internet device can access the server, no one should send a request to it. Therefore, a request is equal to an intrusion into the organisation. Every monitoring server can publish several image objects that are compatible with the injected XSS string to increase the intrusion detection rate. The PhoeniXSS environment is not limited in the number of hosts that run the PhoeniXSS tool and should run in parallel on a number of hosts. Each instance of the PhoeniXSS tool has to include a unique identifier to identify a compromised endpoint. Using the PhoeniXSS with a XSS cheat sheet on a large number of hosts improves the efficiency of the counter-attack.
In this section, implementation details for the PhoeniXSS tool are provided.
PhoeniXSS
We implemented our approach in a POC tool called PhoeniXSS that is composed of two different projects: A. “The Application Verifier (AppVerif.exe) is dynamic verification tool for user-mode applications. This tool monitors application actions while the application runs, subjects the application to a variety of stresses and tests, and generates a report about potential errors in application execution or design” [21]; B. MinHook – “API hooking library that provides basic hooking functionality for x64 and x86 environments” [22]. It replaces the prologue of the target API function with jump instructions to our hook function (i.e., our code). When the hooked function jumps to our code, we can call the API code which follows our jump instruction. The PhoeniXSS consists of a single DLL file (main DLL) that combines the above projects and is injected into the executed binary file at the beginning of the execution, using the Microsoft Application Verifier tool. The PhoeniXSS tool executes binaries files with administrator credentials and hook (i.e., inline hooking) predefined API functions. As many malware programs use COM objects to query end-point hosts, our tool can also hook predefined COM queries. The DLL file of our tool is loaded into the memory before loading the imported DLLs of the execution file. However, hooking predefined API functions is executed after the imported DLLs are loaded into the memory. (i.e., our DLL is executed in the memory and hooks the API function “GetWindowTextA,” which belongs to the User32.dll, only after the last one is loaded into the memory). After our main DLL is loaded into the memory, it hooks the original API function, overwrites the prologue of 8 the function, and jumps to our new code segment. This segment calls the original API function, gets its returned values, and modifies them. This modification adds a specific predefined XSS string to the returned values by the original function. The predefined XSS string consists of an image tag that loads the source of the image from server C. This server hosts a web application that publishes a number of GIF images. Each image is contained in a different XSS string. The length of the XSS string should be minimal to avoid length limitations in the C&C panel DB. In addition, the XSS string should consist of a different characters to evade character limitations in the C2 panel code. The template of our XSS string is as follows: <img/src=//j.en/X.gif> when: – ‘X’ is a number and the name of the GIF image. The GIF image is a transparent image so it can remain stealthy after XSS execution in the browser. Furthermore, the image size is 1X1 pixel, in order to avoid significant overhead requests in the C&C panel and remain stealthy. After the modifications of the PhoeniXSS, the returned values of the API functions appear in the following format: Original Value + Image Tag. For instance, if the original value of the API function “GetWindowTextA” was “explorer.exe”, then after PhoeniXSS modifications, the new value will be “explorer.exe<img/src=//j.en/1.gif>”. “GetWindowTextA” function is an example of one function from the list of predefined functions in our tool. The predefined hooked API functions in the PhoeniXSS tool are “GetComputerNameW”; “GetComputerNameA”; “GetWindowTextW”; and “GetWindowTextA”. The GetComputerName function retrieves the NetBIOS name of the local computer, while the GetWindowText function retrieves the text of the specified window’s title bar. As mentioned earlier, the PhoeniXSS tool also intercepts calls to COM interfaces. It implements “vtable patching” hooking method for the function “ExecQuery” of “IWbemServices” interface. After our main DLL is loaded into the memory, it waits for the “wbemsvc.dll” file to be loaded, to create an object (i.e., an instance) of the above interface and hook the above function. The PhoeniXSS modifies the object’s virtual methods table that contains pointers to all public methods of a COM object, so they can be replaced with the pointers to hook functions. This hook function calls the original function, receives the returned values from it, and adds the above XSS string to them.
Experimental Evaluation
Experimental Setup
Our test environment included three virtual machines (VM) that ran on Intel Core i7- 4720HQ CPU with 16GB of RAM and 230GB of disk space. The first machine is the victim machine, running on a Windows 7 VM, 32-bit, Service Pack 1. This machine was responsible for executing the payload file using the PhoeniXSS tool. We set up another machine to host malware programs’ C&C panels. This host machine ran on a Windows 7 VM, 32-bit, Service Pack 1. Three different browsers were installed on the C&C server with default configuration. Using each of the following browsers – Firefox browser version 53.0.3, Chrome 51.0.2704.103 and Microsoft Edge 38.14393.1066.0 – our detection technique was tested on the collected malware program web panels. The C&C panels of the collected malware programs were hosted on a Windows machine with an Apache web server and MySQL DB. The last machine, our monitoring server, ran on a Windows Server 2008 VM, 32bit, Service Pack 1. 5.2 Experimental Procedure After assembling our test environment, we used our tool to execute the payload of the above collected malware programs. The testing of each malware was performed in a clean and separate image. Moreover, each panel was installed separately from other panels. Our first test was performed on a MegalodonHTTP botnet. MegalodonHTTP, is a piece of malware designed to power distributed denial-of-service (DDoS) botnets. Such botnets can launch seven types of DDoS attacks, open a remote shell on the infected system, mine crypto currency, and kill antiviruses. In order to run, it requires a .NET framework to be installed on the victim’s machine [23]. The MegalodonHTTP communicates with its C&C panel over HTTP in clear text. After building its DB and setting up the web panel of the botnet, we investigated the server-side code of the malware to evaluate XSS vulnerabilities. In addition, we inspected the bots’ information that MegalodonHTTP exposes on its panel, e.g., country name, hardware ID, IP, computer name, operating system, CPU, GPU, RAM, AV type and more. This information is sent to the C&C panel and saved in the DB, yet without validating the input. Therefore, the MegalodonHTTP panel is probably vulnerable to a stored XSS attack. We provided a visual of the MegalodonHTTP panel in Figure 2. Furthermore, another check is required to enable the XSS attack. The stolen 10 information from the bot is sent to the server and is saved in its DB tables. Each table has different fields. These fields have a different length. If the length of these fields is too short for our XSS string, the XSS attack isn’t feasible. There were several fields where their length wasn’t restricted enough. For example, the maximum length of a Windows computer machine is 15 characters and the length of this field in MegalodonHTTP DB is 255 characters. We chose to modify the CPU field value of the infected machine to exploit XSS vulnerability. MegalodonHTTP receives the above value using the following WQL query: SELECT Name FROM Win32_Processor The Win32_Processor WMI class retrieves the processor status and information for both single and multiprocessor machines. The above query returns the processor name value of the infected endpoint. The PhoeniXSS tool is programmed to modify the CPU field value using its ability to hook COM interfaces.
Using the MegalodonHTTP bot builder, we built the payload file with a default configuration and executed it using the PhoeniXSS tool on our victim’s machine. Following execution, information from the victim’s machine was presented on the botnet panel. The injected XSS string of our tool was not displayed on the panel because the browser treated the injected string as the html source of the page. Therefore, from the attacker’s point-of-view, it seemed like the original information was being presented. At the same time, however, the defender (i.e., the victim) detected that its machinehad been infected and that its monitoring server was providing information to the attacker’s machine. A visual of MegalodonHTTP panel after our XSS attack is provided in Figure 3.
Another test was conducted on Dexter malware. “Dexter is a computer virus or point of sale (POS) malware which infects computers running Microsoft Windows. It infects POS systems worldwide and steals sensitive information such as credit card and debit card information and sends it to a C&C server” [24]. The harmful executable installed on the POS endpoint is known as POSGrabber. It is programmed so that it can run as an executable or be injected into another process. The RAM examining process is very straightforward. It initially identifies every single running process, then opens a handle to selected processes and reads chunks of RAM to search for strings of credit card track information. The POSGrabber communicates with the C&C panel is over HTTP. This communication is encoded, and much of it is “encrypted” [8]. One of the main differences between MegalodonHTTP and Dexter malware is the traffic that is sent to their C&C panels. The former’s traffic is sent in clear text, while the latter’s traffic is sent encrypted using Base64 encoding and XOR cipher. Using the PhoeniXSS tool on Dexter malware, we substantiated that our detection technique works on malware programs that use encryption to communicate with their C&C. We followed the same installation steps as with the MegalodonHTTP setup. The panel has three main pages: Dump Viewer, Bot Control, and File Uploader. The first presents the credit card tracks, the second enables the sending of commands to the bots, and shows stolen information from the infected endpoints, while the third page allows the loading of additional files which can then be used by the POSGrabbers. We inspected the server-side code and observed the bot information that was displayed on the Dexter panel and found the following stolen information on bots: UID, Version, IP, user name, computer name, user-agent, operating system (OS), OS architecture, and more. Each field of stolen information in the DB and the methods that were used to retrieve it from the infected machine were inspected, revealing that there was no input sanitisation on the sent information to the Dexter C&C panel. We chose to modify the value of the Computer Name field that is sent to the Dexter panel. The 12 payload file with default configuration was built using the source code of the malware, and then executed in our isolated environment. After execution, the stolen information was presented on the Bot Control page on the panel. The server-side code decrypted the information that was sent to the remote administration panel of the malware, including the XSS string that was injected by the PhoeniXSS tool. The attacker’s browser treated the injected string as the HTML source of the page, thus an infection alert was raised on the defender’s monitoring server. A visual of the Dexter panel after infection is provided in Figure 4.
The final test was conducted on DiamondFox malware, which is multiple purpose, including theft of credit card information as well as credentials at POS systems. It is highly accessible to even the most limited hackers, as it is distributed in many hacker forums. DiamondFox communicates over encrypted HTTP with a key statically built into the C&C and the bots [25].
DiamondFox’s web installation page was used to set up the remote administration panel automatically and configure its bot builder to export a payload file with its key logger module. To substantiate that the DiamondFox panel is vulnerable, we investigated the server-side code of the panel and the received information by the botnet from the victim’s machine. The following information was displayed on the “client’s” page on the DiamondFox panel: ID (based on HID), country, IP, computer name, operating system, and additional information about the victim’s machine (HDD size, RAM size and more). The DiamondFox panel uses several functions to handle data input from its bots before inserting it into its DB. The two most important functions are: A. “mysql_real_escape_string” – “escapes special characters in a string for use in an SQL statement” [26], B. “htmlentities” – “convert all applicable characters to HTML entities” [27]. This input escaping check prevented our tool from exploiting this part of the botnet panel. However, DiamondFox is a multipurpose botnet with a variety of modules, with one of them being its key logging capability. This module also includes an input escaping check on data input, however not on the entire input. A visual of DiamondFox’s key logging module is provided in Figure 5.
The payload used the API function, GetWindowTextA, to track user keyboard typing between different windows. However, the botnet panel failed to validate the data input in function GetWindowTextA, thereby rendering the botnet panel vulnerable to a XSS attack and being detected by our technique. A visual of DiamondFox’s key logging module after using the PhoeniXSS tool is provided in Figure 6.
Countermeasures and False-Positive
XSS attack is one of the most prominent web application security flaw and is currently ranked on the OWASP (Open Web Application Security Project) top 10 chart [28]. However, there are some methods that can prevent such attacks, such as validating and escaping user input. The most efficient method to prevent XSS attack is by escaping user input. Escaping data means taking the data an application has received and rendering it as text by the browser, ensuring it is secure before presenting it to the end user. By escaping user input, key characters in the data received by a web page will be prevented from being interpreted in any malicious way. Key characters such as ‘<’ and ‘>’ are disallowed from being rendered. Validating user input means ensuring an application is rendering the correct data and preventing malicious characters from doing harm to the site and user. However, input validation is not a primary prevention method for vulnerabilities such as XSS and should not be used alone to battle XSS attacks. Although these methods could be efficient in preventing XSS attacks, web applications today still struggle to cover all XSS attack vectors. Furthermore, our use of the XSS attack technique for detecting malware, as described in this paper, is just the first stage of possible future developments for detecting malware. Wide usage of our PhoeniXSS tool, on the other hand, could alert C&C administrators of suspicious scripts in their panels. This result is divided into two: displayed scripts with detection in the C&C panel and displayed scripts without detection. In the 15 first case, we succeed in detecting the attack, with the probable result of the attackers quickly ending their attack campaign, with a probability for mistakes. In the second case, displayed scripts on C&C panels could affect the attackers, taking them out of their comfort zone and leaving them to wonder whether their campaign is free of mistakes or even has been revealed. Finally, many legitimate systems and applications access and query information of endpoints. All systems using, transmitting or displaying this information on a web application are required to receive explicit authorization from the user. In this way, a list of all the legitimate systems can be collected and identified in a defined “whitelist” in advance to avoid false-positives indications. Any other indication will be considered malicious and should be treated with caution.
Conclusion and Future Work
Our work explores a new area of research that may have been overlooked by security research experts. In order to detect malicious activity on endpoint hosts, we developed an innovative detection methodology and a POC for conducting a XSS counter-attack on the C&C web panels of malware programs. By taking advantage of malware vulnerabilities, we demonstrated how our technique is able to detect three different malwares through manipulating endpoint information and utilising trusted communications between the malware and its C&C panel. This research promotes an innovative solution that focuses on the offense, that will enable malware victims to hack back (i.e., conduct a counter-attack) in a legitimate manner. Furthermore, our methodology can be expanded in various directions in the future, such as exploiting SQLI on application panels or using crafted documents to trigger an alert when opened, and more. In future work, we hope to be able to detect new families and variants of malware programs by using all of the above-mentioned techniques in the wild. Such a notion has the potential to change cyber-war rules and create a balanced power relationship between defence and attack forces within the cyber dimension. Adversaries will continue to develop new technologies in order to avoid detection and achieve their purposes. We must not lag behind but must turn the tables on them, using offensive techniques that incorporate new, high-fidelity detection methods.
References
1. Saeed, I., Selamat, A., Abuagoub, A., Abdulaziz, S.: A Survey on Malware and Malware Detection Systems. Int. J. Comput. Appl. 67, 25–32 (2013). doi:10.5120/11480-7108
2. Feily, M., Shahrestani, A., Ramadass, S.: A survey of botnet and botnet detection. Proc. – 2009 3rd Int. Conf. Emerg. Secur. Information, Syst. Technol. Secur. 2009. 268–273 (2009). doi:10.1109/SECURWARE.2009.48
3. Cyber Kill Chain®, https://www.lockheedmartin.com/en-us/capabilities/cyber/cyberkill-chain.html
4. Cross-site Scripting (XSS) – OWASP, https://www.owasp.org/index.php/Cross- 16 site_Scripting_(XSS)
5. Sood, A.K.: Exploiting Fundamental Weaknesses in Botnet Command and Control ( C & C ) Panels. Presented at the (2014)
6. Sood, A.K.: Malware at Stake: For Fun – XSS in ICE IX C&C Panel, https://secniche.blogspot.co.il/2012/06/for-fun-xss-in-ice-ix-bot-admin-panel.html
7. Phase Bot – Exploiting C&C Panel | MalwareTech, https://www.malwaretech.com/2014/12/phase-bot-exploiting-c-pane.html
8. Wallace, B.: A Study In Bots: Dexter, https://blog.cylance.com/a-study-in-bots-dexterpos-botnet-malware
9. Watkins, L., Silberberg, K., Morales, J.A., Robinson, W.H.: Using inherent command and control vulnerabilities to halt DDoS attacks. 2015 10th Int. Conf. Malicious Unwanted Software, MALWARE 2015. 3–10 (2016). doi:10.1109/MALWARE.2015.7413679
10. Goodin, D.: White hats publish DDoS hijacking manual, turn tables on attackers | Ars Technica, https://arstechnica.com/information-technology/2012/08/ddos-take-downmanual/
11. Goodin, D.: Zeus botnets’ Achilles’ Heel makes infiltration easy • The Register, http://www.theregister.co.uk/2010/09/27/zeus_botnet_hijacking
12. Grange, W.: Digital Vengeance : Exploiting the Most Notorious C & C Toolkits Ethics of Hacking back. (2017)
13. Geers, K., Czosseck, C.: The Virtual Battlefield: Perspectives on Cyber Warfare. Netw. Secur. 305 (2009)
14. Dereszowski, A.: Targeted attacks : From being a victim to counter attacking. 1–28 (2010)
15. Rascagnères, P.: Public document APT1 : technical backstage malware analysis General information Hist o ry. 1–48 (2013)
16. Denbow, S., Jesse Hertz: pest control : taming the rats. (2012)
17. Eisenbarth, M., Jones, J.: BladeRunner: Adventures in Tracking Botnets. Botconf. (2013)
18. Gundert, L.: Proactive Threat Identification Neutralizes Remote Access Trojan Efficacy. (2015)
19. Singel, R.: Security Guru Gives Hackers a Taste of Their Own Medicine | WIRED, https://www.wired.com/2008/04/researcher-demo/
20. Watkins, L., Kawka, C., Corbett, C., Robinson, W.H.: Fighting banking botnets by exploiting inherent command and control vulnerabilities. Proc. 9th IEEE Int. Conf. Malicious Unwanted Software, MALCON 2014. 93–100 (2014). doi:10.1109/MALWARE.2014.6999411
21. Application Verifier | Microsoft Docs, https://docs.microsoft.com/en-us/windowshardware/drivers/debugger/application-verifier
22. Tsuda Kageyu: MinHook – The Minimalistic x86/x64 API Hooking Library, https://www.codeproject.com/Articles/44326/MinHook-The-Minimalistic-x-x-APIHooking-Libra 17
23. Kovacs, E.: Alleged Author of MegalodonHTTP Malware Arrested | SecurityWeek.Com, https://www.securityweek.com/alleged-author-megalodonhttpmalware-arrested
24. Dexter (malware), https://en.wikipedia.org/wiki/Dexter_(malware)
25. Wallace, B.: A Study in Bots: DiamondFox, https://www.cylance.com/a-study-in-botsdiamondfox
26. PHP: mysql_real_escape_string – Manual, http://php.net/manual/en/function.mysqlreal-escape-string.php
27. PHP: htmlentities – Manual, http://php.net/manual/en/function.htmlentities.php
28. Top 10-2017 Top 10 – OWASP, https://www.owasp.org/index.php/Top_10- 2017_Top_10
29. Agmon, O., Posener, B.E., Schuster, A., Mu, A.: Ginseng : Market-Driven Memory Allocation.
30. Sharfman, I., Schuster, A., Keren, D.: Shape Sensitive Geometric Monitoring Categories and Subject Descriptors. Pods. (2008). doi:10.1145/1376916.1376958
31. Friedman, A., Keren, D.: Privacy-Preserving Distributed Stream Monitoring. Ndss. 23–26 (2014)
32. Ben-Yehuda, O.A., Ben-Yehuda, M., Schuster, A., Tsafrir, D.: The Resource-as-aService (RaaS) Cloud. Commun. ACM. 57, 76–84. doi:10.1145/2627422
33. Gilburd, B., Schuster, A., Wolff, R.: k-TTP: a new privacy model for large-scale distributed environments. Proc. tenth ACM SIGKDD Int. Conf. Knowl. Discov. data Min. 563–568 (2004). doi:10.1145/1014052.1014120
34. Schuster, A., Wolff, R., Gilburd, B.: Privacy-Preserving Association Rule Mining in Large-Scale Distributed Systems. Proc. Clust. Comput. Grid. 1–8 (2004)
35. Verner, U., Schuster, A., Silberstein, M., Mendelson, A.: Scheduling processing of real-time data streams on heterogeneous multi-GPU systems. Proc. 5th Annu. Int. Syst. Storage Conf. – SYSTOR ’12. 1–12 (2012). doi:10.1145/2367589.2367596