All third generation botnets have specific functionality of grabbing content in the forms present in the web pages. Bots take control of victim machines and use the concept of key-logging to steal data. It depends a lot on the browser architecture and design; how effective the form grabbing technique is applied. This is because malware needs to have full control of the sockets interface and the dependent modules on it. For example:- Internet Explorer uses WININET.dll and Mozilla uses NSPR4.dll. For these browsers, well designed form grabbing key-loggers have been seen in the wild. Zeus and SpyEye bots have inherited functionality that supports form grabbing in IE and Firefox. However, very less infections have been noticed in Google Chrome considering this functionality. This is because Google Chrome architecture is different from other browsers and the low level HTTP request/response handling is done in a bit different way. The question is the possibility of hooking Google Chrome socket interfaces in order to take control of the data that in POST and GET requests mainly. For security reasons, critical data is sent using POST in forms. That's a generic fact.Google Chrome does not use WININET interface to communicate with the server. Google Chrome introduced the support of Web Sockets in order to avoid the complexities of asynchronous communication using XMLHttpRequest (XHR). Web sockets provide an ease of bidirectional communication.
The truth is Google Chrome has also fallen into the hands of predators. Our team has noticed and found traces of effective Google Chrome form grabber that performs incessant hooking into chrome.cpp network interface functions in order to capture all the data and URL to which request is sent. It means, in the coming time we will see bots equipped with robust Google Chrome form grabbing (SpyEye is already started) functionality. Let's have a walk around
1. In first step, Google Chrome PID is detected.
2. The PID maps to Google Chrome executable file (chrome.exe) on the hard disk present in the users directory in order to control the path of the application.
\Device\Hard Disk Volume1\Documents and Settings\Administrator\Local Settings\Application Data\Google\Chrome\Application\chrome.exe
3. The hook module initiates a callback function which is supposed to capture and store the information coming back from forms. The hook is installed in the chrome.exe and injection is initiated. When a user opens a gmail account page and submits data to server, the hook module executes callback function which retrieves the URL and POST/GET parameters before sending it to the server.
4. In order to execute the hook successfully, all the previous Object Entry Points (OEP's) are flushed and new OEP is initiated for different domains.
5. NT_Resume_Thread call is used effectively in the hook procedure and it seems that related hooked functions are found and called during run time based on patterns.
The below presented screenshot shows the debug layout of Google Chrome formgrabber
Nothing is secure as it is proclaimed to be. Welcome Google Chrome to the malicious world?
