Microsoft’s Threat Research and Response blog recently made a post regarding OLE embedded scripts in Office documents and how these can be used to trick a user into double clicking and loading malicious code onto their computer and we are seeing similar trends.
The Carbon Black Threat Research Team researched a new variant of “Retefe,” a popular banking trojan which uses this technique. This variant of Retefe, which targets UK online bankers, uses standard phishing attacks to trick users into enabling malicious content and, ultimately, provide banking credentials.
Interestingly, we found that it leverages Microsoft Office’s object linking and embedding (OLE) capabilities and uses no macros, making the usual protection of disabling Visual Basic for Applications (VBA) useless. Instead, we recommend following the procedure documented by Microsoft here.
While these particular malicious documents require more interaction from the targeted user than some attacks, they are still quite effective due to clever social engineering tactics. Specifically, the malicious actors designed a graphic that was too small to read, and asked users to click the image to read it, thus initiating the attack.
In addition to using OLE, this version of Retefe drops a root certificate and includes a PowerShell script to automate “malicious” clicking on behalf of users.
Variants of Retefe differ slightly, whether it’s the geographical region targeted or incremental advancements in the techniques, such as the use of Powershell and Tor. In this version of Retefe, the dropped certificate helps to keep up the illusion by showing “secure” https connections in the user’s browser. The end goal of this attack is much the same as earlier versions of Retefe – to redirect web logins, (in this latest revision to UK banks) through a proxy to spoofed versions to steal credentials.
This type of attack proves that phishing as a technique is still very viable and most likely profitable, and that the malicious actors behind these attacks are always improving upon their payloads and methods to keep up and take advantage of unsuspecting users.
The Breakdown
Recently, a colleague of mine mentioned he had come across an interesting .doc file that “is a macro-less Word doc with embedded JavaScript, which drops a cert.” That certainly got my attention. My goal here is to breakdown how it worked and demonstrate how to gain visibility and protection from attacks of this style with Cb Response and Protection.
The doc contains a very blurry image, which can be resized, clicked, etc.
Upon zooming in, you can make out what seems to be an itemized receipt.
The text below the image, “Um Quittung zu sehen, klicken Sie zwei Mal auf dem Bild,” is German and translates to: “To see acknowledgment, double click on the image.” When the image is double clicked, the user is prompted with a warning dialog box.
If the user presses ‘OK’, the receipt image will change, revealing what’s really going on.
I was surprised that the “Display logo when script executed in command console” option was enabled in the script properties tab for this embedded OLE object.
If it was unchecked, the receipt image would still be seen after execution and could possibly buy the attacker more stealth.
The image in the document is the replacement picture for an embedded OLE object, in this case a JavaScript script. The JavaScript itself is obfuscated with the “Dean Edwards” packer.
(Bonus points for the arguments to the first function — p,a,c,k,e,d)
The obfuscated JavaScript code drops a certificate and PowerShell scripts into the user’s temp directory. These scripts do the dirty work of installing the certificate and auto-dismissing the pop-up confirmation dialog, as well as registering a new, proxy auto-config URL.
To ensure these new proxy settings are picked up by browsers, the scripts kill all open browser windows so, upon restart, they will use the updated settings. Additionally, the script handles persistence by submitting jobs for the downloaded proxy tool and Tor browser to the Windows Task Scheduler.
In detail, the JavaScript code, once executed by double clicking, does the following:
Drops a root certificate and three PowerShell scripts into the logged-in user’s temp directory. These files are embedded in the script itself as Microsoft ADO Stream Objects, which are then encoded into base64 strings.
Enumerates and kills all browser windows (major three flavors) using taskkill.exe. This is likely to ensure new proxy settings are utilized on restart.
Executes one of the dropped PowerShell scripts, ps.ps1, which loops, looking for the certificate-installation dialog confirmation and, when found, dismisses it by sending it a BM_CLICK window message and exits.
Launches a second PowerShell script, pstp.ps1, with a Tor domain as an argument. This script is setting up proxying browser traffic and persistence.
This script downloads and installs the ‘Task Scheduler Manager Wrapper’ from Microsoft’s CodePlex project.
It then downloads a copy of the Tor browser* and adds it as a job to the Windows task scheduler utilizing the Task Scheduler wrapper with the name “GoogleUpdateTask.” The scheduled job launches the Tor browser via PowerShell, passing it flags to hide the window.
Finally, it downloads a zip file from the Tor domain passed on the command line, which contains the file Proxifier.exe**. It also registers this application as a Task Scheduler job with the name “AdobeFlashPlayerUpdate.”
Installs the dropped certificate using certutil.exe (covering Chrome and IE/Edge), which puts up a modal confirmation dialog. That dialog is dismissed by the already running (and looping) PowerShell script ps.ps1.
The IP address of the current host is determined by connecting to api.ipify.org. If that fails, it resorts to http://icanhazip.com/.
The IP address and the Tor domain passed to pstp.ps1 above are then written to the auto proxy URL registry entry HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL
in the form: http://{tor domain}/{directory}.js?ip={host ip}.
The last PowerShell script, psf.ps1, is executed and installs the dropped certificate into the certificate store for Firefox, which does not utilize the Windows certificate store.
The certificate is a root cert with the common name “COMODO Certificate CA,” which is a valid Certificate Authority. However, this cert was not issued by them, but by the crafters of the trojan’ed document, “me@myhost.mydomain.”
This can all be visualized nicely using the Cb Response console:
To get a little more detail out of the obfuscated JavaScript, I ran it through a beautifier and wrote a small shell script to reverse a long list of backward strings that were used throughout the code.
Strings of interest*** were multiple Tor domains (one is chosen randomly from a list of five when running the script); the command line invocations for taskkill and certutil; the registry key for the proxy auto config URL,which is utilized to route browser traffic through Tor; and some URLs, including icanhazip.com and api.ipify.org for getting the IP addresses of the host being comprimised.
The Tor domains still seem to be up, but the various paths to the auto config javascript file are 404ing. This could be because the IP address I was using for testing was filtered due to geographic location or because things have been changed or updated on the command and control server.
Using Cb Response to Detect & Prevent Retefe
As far as detection and prevention, there are a few options. If you’re running Cb Response in your environment, here are some queries that are good way to see if this, or a similar type of document, has been executed in your enterprise.
process_name:wscript.exe AND childproc_name:certutil.exe
look for wscript mucking with the cert store
process_name:wscript.exe AND filemod:cert.der
look for wscript writing out the cert file, filename is specific, but will find this flavor
Detection of winword launching wscript is built in using the Community feed — “Word Executing Wscript”.
Using Cb Protection
If you’re running Cb Protection, you might want to consider creating a rule to prevent wscript and/or cscript from being launched by Office applications (and consider other major vectors, like Acrobat as well). Also consider blocking PowerShell and certutil from being launched by cscript and wscript.
You’ll want to test these kinds of rules and queries first to make sure there are no impacts to your environment.
Additionally, as mentioned earlier, you can protect your endpoints from executing these embedded OLE objects by following the recommendations from Microsoft in the “Prevention and Recovery Recommendations” section located near the end of the page located here. The change is minor and involves editing a registry key.
______________________________
(*) This command could not be completed due to the directory structure changing (new versions).
(**) These commands/URLs could not be completed/verified due to the Tor hidden service domain’s directory being defunct or moved or due to the IP being used not matching the geographic location being filtered on.
(***)
“taskkill /F /im chrome.exe”
“taskkill /F /im iexplore.exe”
%CERT%”
“network.proxy.”
“psf.ps1”
“certutil1 -?”
“powershell -ExecutionPolicy Unrestricted -File “\”
“HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\AutoConfigURL”
“http://icanhazip.com/”
“cert.der”
“q57zajlxbmj4iaiy.onion”
“cxwfgckwjwlen54k.onion”
“q34vikr2kyreuzri.onion”
“4co7hns6t7qt22ix.onion”
“zm3ztjn2awba7alu.onion”
“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz”
“Ps.ps1”
http://{0}/{1}.js?ip={2}
“http://api.ipify.org/”
“REG_SZ”
“certutil -addstore -f -user “\ROOT”\ “\”
“\\Mozilla\\Firefox\\Profiles”
“pstp.ps1”
“taskkill /F /im firefox.exe”
The post Macro-Less Hacks: Attackers Found Using Office OLE Capabilities to Trick Users and Steal Credentials appeared first on Carbon Black.