Cybercrime News Results In Cybercrime Blues
INTRODUCTION
FireEye Labs recently spotted a 2011 article on cybercrime from the
news site theguardian[.]com that redirects users to the Angler Exploit
Kit. Successful exploitation by Angler resulted in a malware infection
for readers of the article. A spokesperson for the guardian[.]com
responded that they "are aware of FireEye's claims and are
working to rectify the issue in question as soon as possible."
FireEye Labs first detected the activity on Dec. 1, 2015.
Ironically, the affected article was titled “Cybercrime: is it out of
control?” and covered various aspects of cybercrime. As it turns out,
visiting the page shown in Figure 1 and Figure 2 silently redirected
browsers to an Angler Exploit Kit landing page.
Figure 1. Article URL
Figure 2. Image from main page, highlighting
cybercrime issues
The article loaded several other pages and links, including links
for syndication shown in Figure 3 and Figure 4.
Figure 3. Sharing and syndication links
Figure 4. Syndication page URL
When the syndication link is loaded in the background, readers are
eventually redirected to Angler’s landing page via injected HTML that
crafts the request to the Angler landing page.
Visible in the HTML response is the script that would craft the URL
to the Angler landing page. (Figure 5)
Figure 5. Injected script that loads the Angler
landing page
Once loaded, the page would execute the embedded script and redirect
the reader to the Angler landing page located at the URL in Figure 6:
Figure 6. Angler landing page URL
This redirect resulted in a new GET request (Figure 7) that loaded
the landing page (Figure 8) and set up the exploitation stage.
Figure 7. Angler GET request, syndication link URL visible in
Referrer field
EXPLOITS
Old exploits never die…
The use of an OLE Automation vulnerability exploited through
VBScript, along with evidence of potential Flash exploitation, can be
observed in this particular attack.
Angler unconditionally attempted to exploit a popular vulnerability:
href="/content/fireeye-www/en_US/blog/threat-research/2014/11/operation_doubletap.html"
target="_blank">CVE-2014-6332. This is a memory corruption
vulnerability in Windows Object Linking and Embedding (OLE)
Automation, which can be triggered through VBScript with Internet
Explorer as seen below.
The vulnerable code resided in OLEAUT32!SafeArrayRedim, where the
original size of an array was not properly restored when an “Out of
memory” error occured while resizing an array. This issue allowed for
out-of-bounds memory access. In this attack the exploit was based on a
publicly available PoC, and techniques from that PoC were used to
attempt arbitrary code execution. Figure 8 shows Angler’s obfuscated
version of the href="/content/fireeye-www/en_US/blog/threat-research/2014/11/operation_doubletap.html">CVE-2014-6332
vulnerability trigger.
Figure 8. Angler landing page contents
Angler also unconditionally embedded a Flash object in the page at
runtime. The FlashVars included crypto constants for D-H (g, u), and a
URL to the payload (exec). Angler’s server then decided whether to
serve a Flash exploit, presumably based on information in the request
like x-flash-version.
The de-obfuscated object tag used
to embed Flash movie files can be seen below in Figure 9:
Figure 9. Angler CVE-2014-6332 triggering function
It was common practice for Angler to decide which, if any, Flash
exploit to deliver to the target at runtime. Most recently, we
observed Angler delivering a number of high profile exploits. These
included, but were not limited to, href="/content/fireeye-www/en_US/blog/threat-research/2015/07/second_adobe_flashz0.html">CVE-2015-5122,
CVE-2015-5560, and CVE-2015-7645.
Typically, prior to conducting any exploitation on the system,
Angler Exploit Kit attempted to detect whether Anti-Virus products or
analysis tools are present. If Angler determined that such an object
is present, it changed its behavior. For example, if Angler detected
one such product, it invalidated its D-H parameters and the attack
silently failed (Figure 10).
Figure 10. Tag for Flash object from JavaScript
Another change bound to the presence of AV/analysis objects
determines whether or not the malicious VBScript exploit is loaded. If
detected, a non-malicious VBScript will be used instead. Or, it would
if they remembered to unescape the string (Figure 11):
Figure 11. Return appropriate result based on the AV vendor check
This attack was discovered in FireEye Dynamic Threat Intelligence.
Additional syndication URLs are also redirecting to Angler (Figure 12):
Figure 12. Constructing VBScript depending upon the presence of
AV/analysis objects
Visitors to the site are encouraged to use caution to avoid
potentially becoming infected.
Source:
Cybercrime News Results In Cybercrime Blues
