DGA by itself can’t harm you.


But it is an important piece that enables modern malware to try and evade security products and countermeasures.


The importance and usefulness of DGA is best shown by the fact that it’s been in regular and constant use since at least 2008.


DGA was a key component in the Conficker attacks in 2008 and 2009 and part of its success.


What can I do about it?


Because DGA is a technique the fuels malware attacks, the things you can do to help prevent malware can also help prevent DGA-fueled malware attacks:  In addition, new technologies are being developed that can more directly counter DGA-fueled attacks, particularly for organizations.


In particular, security vendors are bringing automation to bear to counter the attackers’ automation.


New anti-DGA technologies that leverage machine learning and big data are capable of countering DGA’s automation with automated prediction of their own that can anticipate, block, assist with malicious site takedowns or even, in some cases, prevent those malicious sites from being used in the first place.


You can also learn more about these new technologies and look at deploying them as an additional layer of protection.


About: Threat Briefs are meant to help busy people understand real-world threats and how they can prevent them in their lives.


They’re put together by Palo Alto Networks Unit 42 threat research team and are meant for you to read and share with your family, friends, and coworkers so you can all be safer and get on with the business of your digital life.  Got a topic you want us to write about for you, your friends, or your family?


Email us at u42comms@paloaltonetworks.com.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Unit 42 released details about a vulnerability that affects Android devices running operating systems older than 8.0 Oreo.


The vulnerability leaves Android users at risk of falling victim to an Android Toast Overlay attack.


Patches are available that fix this vulnerability, so Android users should get the latest updates as soon as possible.


How it Works


The vulnerability affects the Toast feature on Android devices, an Android feature that allows display messages and notifications of other applications to “pop up,” and allows an attacker to employ an overlay attack.


An overlay attack happens when an attacker places a window over a legitimate application on the device.


Users will interact with the window, thinking they are performing their intended function, but they are actually engaging with the attackers overlay window and executing the attacker’s desired function.


You can see an example of how this would work in Figure 1.


Figure 1: Bogus patch installer overlying malware requesting administrative permissions  This interaction can install malware or malicious software on the device, grant malware full administrative privileges or lock the user out and render the device unusable.  In the past successful overlay attacks were typically dependent on two conditions:  However, with this particular vulnerability, these conditions are no longer required for a successful attack.


This means that attackers can use this vulnerability in apps users get from places other than Google Play.


And when they install these malicious apps, they don’t have to ask for the “draw on top” permission.


How to Defend Against It  Keeping devices updated is a general security best practice.


The Android Toast Overlay attack specifically targets outdated devices using versions prior to 8.0.


In order to defend against the Android Toast Overlay attack, update all Android devices to the latest version.


Additionally, avoid downloading malicious applications by only downloading from the Google Play store is another best practice you should always follow.


Please mark, I'm not a robot!


This post is also available in:      日本語 (Japanese)  Ransomware is one of the top threats in cybersecurity and a focus area for Palo Alto Networks.


In the current threat landscape, ransom payments are rising and organizations are seeking to protect themselves from threat actors.


In the 2021 Unit 42 Ransomware Threat Report, we detailed the observations and the trend of top ransomware families from January 2020-January 2021.


This post supplements that information based on observations from the first three months of 2021, and will discuss the propagation of different ransomware families we observed in the wild and the different types of extortion used.


We hope the information will help readers get a clear picture of current directions in ransomware trends.


In the first quarter (Q1) of 2021, Unit 42 detected 113 different ransomware families in the wild.


Based on the statistical data, the top 15 ransomware families only cover 52.3% of total ransomware cases.


This demonstrates the diversity of ransomware and emphasizes how difficult it is to expand ransomware detection coverage with static profiling.


Figure 1 shows the proportion of ransomware sample numbers for different families that Unit 42 detected in the wild.


Among all, 6.7% of the ransomware samples are Virlock, which has been active since 2014.


Virlock has the largest number of variants due to its file-infector-like behavior.


Higher malware variant numbers don't necessarily imply a higher prevalence.


Some ransomware families don’t deliver different variants every time, but the infection ratio per sample is high, meaning attackers delivered the same malware to huge numbers of victims.


Figure 2 shows a completely different result from Figure 1 and stems from only counting ransomware samples from cases in which more than five hosts were infected with the same malware.


From this lens, the top three families observed are Ryuk (31.7%), Sodinokibi (20%) and Maze (15%).  Emails are still the most efficient method to deliver and propagate ransomware.


Figure 3 shows ransomware arrives via different application protocols.


The majority of ransomware is delivered by email.


Web browsing is the second most common entry vector for ransomware infections.


The process of delivering malware by a URL can include various techniques.


For example, the URL links can be posted on forums or chat group software, sent by IM applications, offered via fake freeware for download or attached in emails.


Web hosting ransomware can also be downloaded and successfully installed through a multi-layered infection chain among different file types.


For example, AlumniLocker is first delivered as a phishing PDF.


It leads to downloading a ZIP archive that contains an LNK downloader.


This downloads and executes an obfuscated PowerShell script to finally install the ransomware.


Figure 4 breaks down which file types we saw in the course of ransomware detection and their prevalence.


32-bit EXE is the most common ransomware file type we observed.


Other file types are often used as the first stage of infection or downloaders, such as archives, documents and scripts.


Most ransomware is delivered via email with an attached archive; the ransomware is compressed in the archived files with or without password protection.


“Resume” or “portfolio document” are examples of archive file names, and the archive contains one or more pieces of malware with fake document file icons.


One example here is Makop, contained in a 7z archive along with an infostealer malware (SHA256: DE6DFA018773E07C218EF1DF62CE0D99A708841BF1DDFB4C6AD7E323D5D666A4).


A script file is also used to download or install ransomware.


For example, GandCrab uses JScript as a downloader, leveraging Windows Background Intelligent Transfer Service (BITS) to download the payload in the background (Figure 5).


We also observed that Mailto (AKA NetWalker) tends to deliver ransomware in a highly obfuscated PowerShell script.


Exploit documents are seldom seen for delivering ransomware.


One example is an exploit RTF that led to downloading and installing Makop ransomware remotely.


Besides encrypting files on infected hosts, the main feature of ransomware is, of course, the demand for ransom.


Since ransomware threat actors have had years to evolve their techniques, there are now several different ways for attackers to receive payments and provide the "service" they claim to offer.


Usually, after the ransomware successfully installs, it pops up a message box or leaves text files to explain how to pay the ransom – the ransom note.


Some ransomware locks the victim's screen and only displays the ransom note.


Unit 42 has reviewed ransom notes from different ransomware families.


Most ransom notes request payment in cryptocurrency or mention reaching out via the darknet, though some other contact methods also appear.  In these cases, the ransom note asks victims to pay a specific amount in cryptocurrency – Bitcoin (BTC), Monero (XMR), etc. — to a specific wallet address.


Two ransomware families that utilize these types of ransom notes are Virlock and WanaCrypt0r.


Some ransomware families, including Babuk, Sodinokibi, Cerber, Mailto, Ryuk and others, seldom show the ransom amount or cryptocurrency wallet address.


Instead, they instruct victims to install TOR and reach out to them on the darknet.


Usually, they host a website for victims to input the identification key found in the ransom note, upload encrypted files for decryption – and pay the ransom.


Ransom notes from Makop, Dharma, Ryuk, DearCry and others, sometimes ask victims to reach out to them via email.


The email addresses given are usually from untraceable email accounts.


At other times, a threat actor lets the victim chat with them directly on group chat software.


The victims can find the threat actor’s user name through specific group chat software or follow a chat group link in the ransom note.  Ransom payment operations are complicated and highly automated processes.


Attackers can create a lot of cryptocurrency wallets automatically; they can even make a unique wallet address for each victim.


Once a ransom is received, the ransom will be involved in the multiple transactions that are managed to distribute and aggregate the ransom across thousands of virtual wallets.


For example, the Xorist ransomware (SHA256: 4979A10B81C41ECC0FC3A0F376ADE766CE616D2301639F74E0277047CC40E3D6) demanded £1,000 for a ransom; the bitcoin wallet address was 1BFqrLCDwwrxueY7FFDn8DqeoasPJignxt.


However, this wallet had not really received any ransom payments when the malware was delivered.


The wallet got involved in the operation of mixing and tumbling among several other virtual wallets.


This is a pretty common operation when attackers want to withdraw or disperse currency from ransom payments into other wallets.


During the operation, 25.1 BTC from 538 wallets was sent to 1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s (SHA256: CE11703DEF517306326C48A67A7C859A3DE0F18E2451DF226CE171389A5B7953), which is a wallet owned by Binance cryptocurrency exchange.


(ref: Binance on Twitter ).


The 25.1 BTC amount was worth $1.18 million at that time, and now is about $876,000.


Since Virlock only requests a $250 ransom, it does not draw too much public attention.


Other ransomware families, however, target enterprises and ask for multimillion dollar ransoms, which garners much more media attention.


Based on the way Virlock spreads the ransom amount it demands, it is likely designed to target consumers or home users.


After infection, Virlock hides the file extension through modification of the registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\HideFileExt = 1, HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden = 2).


The encrypted file icon will look the same as usual, but after opening the infected file, the ransom note will pop up.


Virlock uses, but isn’t limited to, PDF, DOC, PPT, JPG, BMP,GIF, RAR, 7Zip, Zip and EXE files.


Figure 6 is a screenshot of a recently captured Virlock ransom note.


The attacker asked for $250 and required payment as 0.004 BTC (suggesting that at the time the ransom note was written, 1 BTC equaled approximately $62,500).


At the time of infection experiments, 1 BTC equaled approximately $54,649, suggesting that the exchange rate in the ransom note is not updated on the fly.


Some Virlock variants ask for more ransom, such as 0.771 BTC, 1.008 BTC or more.


The top three samples we observed spreading in early 2021 were Ryuk, Maze, and Sodinokibi.


These three contribute 7.2% out of the total infected numbers we collected.


Ryuk will change the infected file extension to .RYK, and leave a ransom note called RyukReadMe.html.


One of the reasons Ryuk causes so much damage is because it will scan the local network and try to infect other machines through Server Message Block (SMB) protocols.


Ryuk will even send out Wake-on-LAN packets to wake up systems that have been configured with this feature.


In this research, we discussed ransomware family trends we observed in the first three months of 2021.


First, we reviewed the trends from prevalent ransomware families, then we discussed the most common file types used as attack vectors leveraged by ransomware.


Lastly, we gave an example of ransom operations and updates about top ransomware families.


Ransomware threats are a serious challenge.


Employing effective backup strategies and disaster recovery procedures is important.


Palo Alto Networks customers are further protected from ransomware.


Cortex XSOAR can automatically and instantly coordinate with network security, malware analysis and threat management solutions to ensure customers remain protected.


Cortex XDR endpoint protection stops malware, exploits and ransomware before they can compromise endpoints.


With AI-powered Inline analysis, the Next-Generation Firewall stops exploits that lead to infection, and WildFire’s always up-to-date machine learning models monitor behavior to preemptively detect unknown ransomware.


If you think you may have been impacted by ransomware, please email unit42-investigations@paloaltonetworks.com or call (866) 4-UNIT42 to get in touch with the Unit 42 Incident Response team.


Highlights from the 2021 Unit 42 Ransomware Threat Report  Ransomware Threat Assessments: A Companion to the 2021 Unit 42 Ransomware Threat Report  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


If you need to understand one thing about cybercrime, it’s that it is all about business.


In our latest Unit 42 research on cybercriminals using the Hancitor malware, we show that not only are their attacks about business, we can see these cybercriminals deftly applying some fundamental business principles around timing, specialization, and globalization.


Hancitor is a malware that focuses getting other malware onto the victim’s system.


In the case of Hancitor, it’s typically banking Trojans that steal the victim’s banking information.


In our latest research, we can see the attackers behind Hancitor have been timing their attacks to happen during the busiest time of the global working week, the middle of the week.


And we’ve seen that in adapting their attacks to better evade detection, they’ve specialized their operations around the globe.


Hancitor isn’t particularly advanced in its tactics: it’s ideal target is an old or outdated version of Microsoft Windows like Windows 7 or even Windows XP.


But it’s effective enough that when used in several hundred different spam campaigns every month it pays for the criminals to keep up these attacks against targets around the world.


Timing   In our most recent research, one of the things that jumped out for our researchers is the clear pattern around the timing of the attacks.


As you can see in Figure 1 below, throughout 2017, the Hancitor attacks show clear spikes in their occurrence and these spikes happen during the middle of the week.


Figure 1: Timeline of Hancitor campaign activity since January 2017.


The attackers behind Hancitor aren’t the first to time their spam attacks like this, but it is an effective tactic to try and increase their chances of success, especially when combined with the other innovation that we’ve seen.


Adapting the Attacks


In the past, Hancitor was sent as a malicious attachment in a spam email which would then download and install the attackers’ final malware like a banking Trojan.


When they would do this, the Hancitor attachment would download and install the final malware from a malicious or compromised site.


But as organizations have gotten more effective at blocking malicious attachments like Hancitor, we’ve seen the attackers behind Hancitor adapt to evade detection and prevention.


They’ve done this by moving the Hancitor malware from being a malicious attachment in spam to itself being a malicious download.


The spam the attackers use no long has a malicious attachment but instead a malicious link that downloads the malicious Hancitor attachment.


To do this, they make the spam look like something that requires you to click and download something like and invoice, a message, or a delivery notification.


Figure 2 shows one of these that was made to look like an Amazon shipping notice.


Figure 2: Hancitor malspam example from February 2017.


This means that a Hancitor attack now has two downloads rather than one and what these attackers did around the malicious downloads shows another modern business tactic: globalization.


Globalizing the Attacks  Figure 3 below is a map showing where our Unit 42 researchers have found webistes involved in Hancitor attacks.


Figure 3: Hancitor distribution servers globally thus far in 2017  Table 1 – Number of Distribution Servers by Country


The hot spots in the United States represents distribution servers which are created using fraud based accounts at various hosting providers that are hosting the Hancitor documents while the hotspots in Asia represent legitimate sites for small and medium businesses that have been compromised by the actors behind Hancitor campaign to host the malicious Hancitor documents.


Conclusion  Attackers are always making business decisions to optimize their attacks in ways that are most successful and profitable.


What is most interesting about Hancitor is the way these decisions so clearly reflect an awareness of business realities (by targeting peak working times) and dividing up the “work” of their attacks in a way that so clearly mirrors mainstream business decisions around globalizing operations.


In the end, while Hancitor may not be sophisticated, these steps to adapt and stay effective seem to be succeeding.


And we expect to continue to see Hancitor be a global threat for the foreseeable future.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  This Unit 42 blog provides an update on the threat situation surrounding attacks using the Petya Ransomware which are impacting organizations in Ukraine, Russia and to a lesser extent around the world.


On June 27th, 2017 we became aware of a new variant of the Petya malware which is spreading through multiple lateral movement techniques.


One technique includes  the ETERNALBLUE exploit tool.


This is the same exploit the WanaCrypt0r/WannaCry malware exploited to spread globally in May, 2017.


At least 50 organizations have reported impacts from the malware, including government and critical infrastructure operators.


Palo Alto Networks is documenting our prevention capabilities with regard to this threat in the Palo Alto Networks Protections for Petya Ransomware blog post.


Windows users should take the following general steps to protect themselves:


This is a developing situation, we will update this blog as new information becomes available.


AutoFocus users view samples using the Petya tag.


Petya is a ransomware family that works by modifying the Window’s system’s Master Boot Record (MBR), causing the system to crash.


When the user reboots their PC, the modified MBR prevents Windows from loading and displays a fake “chkdisk” screen which indicates the computer's hard drive is being repaired, but the malware is actually encrypting the user's files.


When this process completes, the malware displays an ASCII Ransom note demanding payment from the victim (Figure 1).  Figure 1: Latest Petya Ransom note displayed on a compromised system.


The latest version of the Petya ransomware is spreading over Windows SMB and is reportedly using the ETERNALBLUE exploit tool, which exploits CVE-2017-0144 and was originally released by the Shadow Brokers group in April 2017.


After the system is compromised the victim is asked to send US $300 in Bitcoin to a specific Bitcoin address and then send an e-mail with the victim’s bitcoin wallet ID to wowsmith123456@posteo[.]net to retrieve their individual decryption key.


Posteo (a free e-mail provider) has already shut down this e-mail address, and as such victims should not even attempt to pay the ransom.


As of 13:00 UTC on June 28thth, approximately 4 Bitcoin have been transferred to the attacker's wallet.


Unit 42 is unaware of ANY successful recovery after paying the ransom.


Additionally, ongoing research by the industry is showing that specific actions this malware takes makes it technically infeasible, if not impossible, for recovery to occur.


This means that even though this malware is functionally ransomware, for threat assessment purposes, it should be functionally considered a “wiper”.


We are aware of the following information about how the Petya attack lifecycle works.


Delivery/Exploitation


We have not yet confirmed the initial infection vector for this new Petya variant.


Previous variants were spread through e-mail, but we have not identified this latest sample carried in any e-mail related attacks.


While we have not been able to directly confirm the source, we have seen evidence that a Ukrainian software application called MEDoc was used by attackers to deliver the Petya DLL.


The software is heavily used in Ukraine it appears the company’s systems may have been compromised and used to issue a malicious update to systems running the program on the morning of Jun 27th.


Installation


This variant of Petya is spread as a DLL file, which must be executed by another process before it takes action on the system.


Once executed, it overwrites the Master Boot Record and creates a scheduled task to reboot the system.


Once the system reboots, the malware displays a fake “chkdisk” scan which tricks the victim into believing the program is repairing their hard drive.


In reality, the malware is encrypting the NTFS Master File Table in the background.


Once the fake chkdisk completes, the malware displays a ransom note which demands a payment of $300 in bitcoin.


Command and Control  Petya contains no Command and Control mechanisms that we know of.


After a host is infected, there is no communication from the malware back to the attacker.


Lateral Movement  Petya uses three mechanisms to spread to additional hosts.


Ransomware attacks are very common, but they are rarely coupled with an exploit that allows the malware to spread as a network worm.


The WannaCry attacks in May, 2017 demonstrated that many Windows systems had not been patched for this vulnerability.


The spread of Petya using this vulnerability indicates that many organizations may still be vulnerable, despite the attention WannaCry received.


As always if you have any questions, please come to the Threat & Vulnerability Discussions on our Live Community.  Version Summary  June 27, 2017:  June 27, 2017 – 1:08 PM PT  June 28, 2017 – 8:40 AM PT  June 29, 2017 - 5:00 PM PT  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Nearly all of us have a use for Microsoft Office documents.


Whether they are work documents, e-receipts, or a lease on a new apartment – Office documents are useful to all of us, and this is part of the reason we’re very likely to open an office document we receive as an attachment in e-mail.


Armed with the knowledge that many people will open nearly any document, even those from an untrusted source, adversaries commonly choose these files in attacks to compromise a system.


In this threat brief we show you five different ways that Office documents can be subverted and abused to attack and compromise a Windows endpoint, some we’ve already posted about before, and some are new.


Macros Macros are the most straight-forward way for an attacker to weaponize Office documents.


Office applications have a built-in script engine that can run VBA (Visual Basic for Applications) scripts.


These scripts can execute immediately as the document opens, without any user interaction (assuming the user has previously enabled macros) and run malicious code on the system.


If the user has not enabled macros, a popup window will appear asking the user to click to do so.


The pop-up is one of several security mechanisms added by Microsoft to mitigate the security risk that macros pose.


Microsoft will also force a different file extension (.docm instead of .docx for new documents containing macros).


Despite these measures, users still choose to open these files and enable their content, thus allowing macros to continue be a common attack vector – both in wide and simple attacks to deliver ransomware such as Emotet, as well as for sophisticated attacks like this Sofacy campaign.


Figure 1.


The Sofacy document before & after the content is enabled


As you can see in this example, attackers try to convince users to disable the security mechanisms added by Microsoft using social engineering, convincing the user to enable content for them to be able to see the full document.


In the Sofacy example, the attackers had simply made the font color white, so the text was present prior to the user enabling macros, just not clearly visible.


Embedded Flash files  In addition to built-in capabilities, like macros, Office documents can also be embedded with external objects, such as Adobe Flash files.


These objects are passed to the appropriate software for handling, thus any vulnerability that the software has can also be exploited by embedding it within the Adobe Flash content in the Office document.


An example for such attack vector being leveraged by attackers is CVE-2018-4878, an Adobe Flash Player Zero-Day exploited by embedding malicious SWF files in Excel documents.


In these types of attacks, the malicious Excel contains embedded Adobe Flash content which can trigger the Flash vulnerability and execute embedded shellcode.


Microsoft Equation Editor


In a similar way to embedding Adobe Flash files into an Office document, you can also embed equations in documents that will be parsed by Microsoft Equation Editor - a program that lets you easily write mathematical equations: Figure 2.  Microsoft Equation Editor  As in our previous example, vulnerabilities in the equation editor can be exploited by leveraging malicious Office documents.


We’ve seen examples of this just recently, when CVE-2017-11882 was exploited in the wild, paving the way to other exploits like CVE-2018-0802, both of which exploit flaws in the equation editor, enabling attackers to get from the user opening an Office document to remote code execution.


While still not seen in the wild, similar exploits in Microsoft Equation Editor, such as such as CVE-2018-0807 and CVE-2018-0798, were identified by Unit 42 researchers.


Note that since the Microsoft Equation Editor runs as its own process (eqnedt32.exe), protections specific to Microsoft Office such as EMET and Windows Defender Exploit Guard are not effective by default, as they only protect Microsoft Office processes (such as winword.exe).  OLE Objects & HTA Handlers


OLE Objects & HTA Handlers are mechanisms Office documents use to make references to include other documents in their content.


They can be used to compromise an endpoint in the following way:  This functionality was leveraged in exploitation of CVE-2017-0199 - a Microsoft Office/WordPad remote code execution (RCE) vulnerability patched by Microsoft in September 2017, and was used in multiple campaigns, like this OilRig campaign.


Figure 3.


RTF files will look exactly like regular Word documents


In addition to the previous OLE & HTA exploit, attackers discovered RTF files can also execute ‘text/html’ mime-type OLE objects using the MSHTML.


This means that RTF documents expose the same attack surface as Internet Explorer!


Leveraging this logical vulnerability, known as CVE-2018-8174, allows attackers to execute arbitrary HTML/JavaScript/VBScript.


While code executed in this way is ‘sandboxed’ (where it cannot run new processes or write to the filesystem etc.), like other code running from Internet Explorer


, this flaw can be used to leverage other vulnerabilities, such as a memory corruption UAF vulnerability in the VBScript engine, to gain arbitrary code execution in the context of the Word application (winword.exe), allowing them to gain control on the system.


Conclusion


While document-based attacks have been a common attack vector for over a decade, we’re seeing a recent rise in their popularity and complexity.


This rise may be a result of browser exploits becoming more difficult to use, due to the hardening done by browser developers.


No matter the reason


, it is important that organizations know how to defend against these common techniques.


Prevention Palo Alto Networks Traps advanced endpoint protection offers multiple methods of malware and exploit prevention to protect against these threats:


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This has been a fun week.


We have not had a significant cyber event like this – something that affects just about everybody on the Internet -- since the Kaminsky DNS vulnerability of 2008.


Everybody I know has been scrambling to understand what it means to their organization, to their business and to their immediate family.


Yes, I said family.


I am sure I am not the only one who has answered a question or two from his mother-in-law about how the Internet is melting down based on what she’s been reading in the press.


There’s a lot out there already about what Heartbleed means for the Web and beyond, and I’ll point you to our own analysis written by Scott Simkin or an essay by Dan Goodin over at ars technica for that explanation.


Instead, here are eight things I am doing right now to protect Palo Alto Networks and my home (and mother-in-law) and that you should be doing, too:


If there’s a long-term consideration here, it’s to install perfect forward secrecy, as Twitter did last year.


That ensures that a session key derived from a stolen private key and a collected public key in the future will not be compromised.


For more:  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


This post is also available in:      日本語 (Japanese)  On Aug. 25, 2021, Atlassian released a security advisory for an injection vulnerability in Confluence Server and Data Center, CVE-2021-26084.


If the vulnerability is exploited, threat actors could bypass authentication and run arbitrary code on unpatched systems.


Since the release of this advisory, mass scanning activity has started to occur, seeking unpatched systems, and in-the-wild exploitation has begun.


Unit 42 recommends customers upgrade to the latest release of Confluence Server and Data Center.


The Atlassian products vulnerable to CVE-2021-26084 are those using the following versions of Confluence Server and Data Center:  Confluence Cloud customers are not affected by this vulnerability.


We recommend that customers update Atlassian Confluence Server and Data Center to the latest version, 7.13.0 (TLS).


You can find the newest release on Atlassian’s download center.


If you cannot install the latest upgrade, see the Mitigation section on the Atlassian security advisory for information on how to mitigate this vulnerability by running a script for the operating system your Confluence server is hosted on.  Palo Alto Networks provides protection against the exploitation of this vulnerability:  Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.


writeups/Confluence-RCE.md at main · httpvoid/writeups  Confluence Server Download Archives  Confluence Security Advisory - 2021-08-25 | Confluence Data Center and Server 7.13


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  On Sept. 14, 2021, Microsoft’s Security Response Center (MSRC) released security patches detailing the findings of four critical vulnerabilities affecting the Microsoft Azure package Open Management Infrastructure (OMI).


The open-source OMI package is designed to provide a portable infrastructure backbone for web-based management tools, such as diagnostic monitoring, log analytic services and automation functionality within UNIX and Linux systems.


OMI is used by Microsoft Azure to manage UNIX packages within Azure virtual machines (VMs), containers and serverless cloud instances.


According to Microsoft’s security release notes, any system created, or which has updated its OMI package, after Aug. 11, 2021, should automatically be patched.


The four critical vulnerabilities discovered by security researchers from Wiz include one unauthenticated remote code execution (RCE) and three privilege escalation vulnerabilities.  Dubbed OMIGOD, the four vulnerabilities were found to directly affect Azure cloud instances using the following Azure services:  Prisma Cloud Compute Defender agents can detect whether any Azure system is vulnerable to any of the four CVEs.


Additionally, Prisma Cloud users can also build a custom vulnerability detection rule to identify if any system is running an OMI package with a version previous to 1.6.8.1.


To build a custom vulnerability detection rule, open Prisma Cloud and navigate to the following page:  name,type,package,minVersionInclusive,maxVersionInclusive,md5 OMIGOD,package,omi,*,1.6.8.0,  Palo Alto Networks Azure-based VM- and CN-Series Firewall instances do not use the OMI package and are not vulnerable to the OMI critical vulnerabilities.


Prisma Cloud will create an alert for any system which maintains an OMI package vulnerable to the OMI critical vulnerabilities.


Should a system be identified as vulnerable, the following steps should be taken for that Azure Cloud Instance:


On Sept. 14, 2021, security researchers from Wiz released a report detailing the findings of four critical vulnerabilities affecting the Microsoft Azure package OMI.


Dubbed OMIGOD, the four vulnerabilities were found to directly affect Azure Cloud Instances.


Palo Alto Networks Azure-based VM and CN Series Firewall instances do not use the OMI package and are not vulnerable to the OMI critical vulnerabilities.


Customers of Prisma Cloud have the ability to create alerts to detect vulnerabilities.


Use-after-free bugs have affected Internet Explorer for years.


In the past year alone, Microsoft patched 122 IE vulnerabilities, the majority of which were use-after-free bugs.


This year Microsoft has already patched 126 IE vulnerabilities to date.


Of those vulnerabilities, 4 were actively being exploited in the wild.


These 4 exploits (CVE-2014-1815, CVE-2014-1776, CVE-2014-0322, CVE-2014-0324) were all based on use-after-free bugs.


To deal with the increasing number of use-after-free bugs and associated exploits, Microsoft introduced a series of new control mechanisms in the most recent Internet Explorer patches.


In June, Microsoft introduced a new isolated heap mechanism to solve the usage issue of use-after-free exploitation.


They followed that up In July by implementing a deferred free method to solve the freeing issue of use-after-free bugs.


The main concept of an isolated heap is simple.


It allocates a dedicated heap for select critical objects to use that is separate from other heaps that a user can directly access.


The heap block will not be occupied by user-controlled data after the critical objects are freed.


This mechanism prevents precise control of the data of a freed object from further exploitation.


Figure 1. _g_hIsolatedHeap handle used for isolated heap


The isolated heap was applied to many but not all internal objects, leaving some still vulnerable.


To address this, Microsoft introduced another protection method of deferred free named ProtectedFree.


They encapsulate this method and apply it to almost every object in mshtml.dll.


In IE9, for example, it has been applied to every object through MemoryProtection::HeapFree as shown in figure 2.


Figure 2.


References of MemoryProtection::HeapFree


The main idea of this protection mechanism is to delay the freeing action so that the intruder is unable to determine when they can occupy the freed object using controlled data.


In this new patch, every time Internet Explorer tries to free an object, it is not freed immediately.


Instead, the block to be freed is marked and filled with 0x00 data and added to a pool.


When the size of the pool hits a predefined threshold, which is currently 100k (0x186A0 as highlighted in figure 3), it performs the real freeing operation (ReclaimUnmarkedBlocks).    Figure 3.


C++ style pseudo code of ProtectedFree function


Microsoft stores the to-be-freed blocks in a structure called st_ProtecFreeManageHeap.


This structure is created in the function MemoryProtection::CMemoryProtector::ProtectCurrentThread and is used to manage deferred free heap blocks.


Figure 4 shows an example of the structure in memory.


Figure 4. st_ProtecFreeManageHeap  Figure 5 provides an alternate view of the structure in a C style code block.


Figure 5. C style code of st_ProtecFreeManageHeap


If we were able to make the size of the current heap block in this structure larger than the threshold of 0x186A0 bytes and trigger CMemoryProtector::ProtectedFree, it is still possible to force a true freeing action and occupy the freed object with other data as we show in the following piece of javascript code in figure 6.    Figure 6. Javascript proof of concept to force freeing  When creating the anchor element, the debug logs are shown in figure 7.


The address of the anchor element is 0x0c3b3f98.


Figure 7:


Before free  We then manually decrease the reference number, so the CMemoryProtector::ProtectedFree function will fill the block with 0’s, but the object is still not freed.


Figure 8: decrease the reference number, not yet freed


Finally we make the size of the CMemoryProtector::ProtectedFree management structure larger than 0x186a0 forcing the freeing operation.


Figure 9: field “TotalMemorySize” of st_ProtecFreeManageHeap is greater than threshold


The anchor element is now actually freed as shown in figure 10.


Figure 10: object is in the free list now


From a researchers' point of view, deferred free created a few problems, one of the major ones being that the page heap feature may not work correctly.


Page heap is a useful feature for debugging.


When page heap is turned on, the system allows only one object in one memory page.


Once this object is freed the whole page is marked as invalid.


So the next time IE tries to access a freed object an invalid address exception would be raised.


This mechanism is extremely helpful when researchers are trying to find use-after-free bugs.


With the introduction of the deferred free patch the object is no longer truly freed, so the page still exists.


In this situation the researcher is no longer able to determine whether a use-after-free behavior has occurred because no exception would be thrown out.


To reduce the impact of the deferred free patch, a research may consider patching the mshtml.dll in memory.


For example, you can call MemoryProtection::CMemoryProtector::UnprotectProcess before you perform any fuzzing tasks.


The recent patches and introduction of isolated heap and deferred free are strong signs that Microsoft plans to address the fundamentals of use-after-free exploitation in a preventative manner rather than to passively patch the vulnerabilities as they are discovered.


From the results of our research, applications of such methods can effectively stop unpatched use-after-free attacks.


It can also make the exploitations of heap overflows or type confusion bugs significantly more difficult.


But this is not the end.


For the foreseeable future, Microsoft may introduce more defensive mechanisms against use-after-free bugs or even heap fengshui to reduce the risk of being exploited.


Could it be game over for use-after-free exploitation, or it is just the beginning of another cat and mouse game?


Time will tell.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Today we’re releasing a new Unit 42 white paper titled “Credential-Based Attacks: Exposing the Ecosystem and Motives Behind Credential Phishing, Theft and Abuse.”


In this paper, we look at the problem of credential theft by exploring how it happens, what attackers do with credentials once they’ve stolen them, and what you can do to help prevent credential-based attacks.


Credentials and authentication have become synonymous, with valid credentials allowing access to sensitive resources.


Adversaries are increasingly stealing and using credentials as part of their playbooks; impersonating legitimate users to access a company’s most sensitive information, erase data on servers, and reconfigure them so that they can’t boot; and undertake other malicious activities.


Stolen credentials underpin some of the most critical and damaging attacks out there; both Shamoon 2 and the Sofacy threat actor group, for example, have made detailed use of credential theft.


Credential theft today can happen in many ways, but the most notable are through credential phishing and the use of malware like keyloggers (both staples of the Sofacy group), as well as password reuse.


The impact of a successful credential theft is, ultimately, access and authorization.


Attackers will use credential theft for remote access to an organization, to access cloud-based resources (which may have weaker credential protections than network-based resources), or to move laterally within an organization once they’ve gained entry.


The most sophisticated attacks can – and do – blend these actions together, sometimes using multiple stolen credentials to penetrate networks, move laterally within them, elevate privileges, and then access and steal data.  Prevention of credential theft is too often overlooked.


Organizations should continue with user education to help users better spot and not fall for phishing and spam attacks.


You and your employees can also use password managers to make unique, complex passwords for each site not just a goal but a reality.


Technology is also catching up; recent advances in two-factor/multi-factor authentication (2FA/MFA) and one-time passwords (OTP) represent the best long-term approaches to preventing credential theft.


(Our newest release, PAN-OS 8.0, also includes protections to significantly limit or eliminate password reuse.)


Get your copy of our white paper here.


Ignite '17 Security Conference: Vancouver, BC June 12–15, 2017  Ignite '17 Security Conference is a live, four-day conference designed for today’s security professionals.


Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry.


Visit the Ignite website for more information on tracks, workshops and marquee sessions.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  In January 2020, during the first Patch Tuesday of the new year, Microsoft released patches for 17 new vulnerabilities including one for CVE-2020-0601 known as Curveball.


The vulnerability exists in the Windows CryptoAPI (Crypt32.dll) and specifically relates to the method used for Elliptic Curve Cryptography (ECC) certificate validation.


At the time of release, Microsoft affirmed that they had not yet seen the vulnerability exploited in the wild (ITW).


Researcher Tal Be’ery released a blog titled “Win 10 Crypto Vulnerability: Cheating in Elliptic Curve Billiard 2” that does a fantastic job at explaining this bug.


The patch provided by Microsoft included the typical release of operating system patches, but this time a new Application Programming Interface (API) function was added.


The new CveEventWrite function can be used to publish events when an attempt to exploit security vulnerabilities in user-mode applications occurs.


Analysts can collect alerts on the Application Message “CVE-2020-0601” as a means to hunt for attempted exploitation of this vulnerability on patched systems.


We also recommend users of the Chrome browser to update to version 79.0.3945.130 as they recently released an update to fix the TLS issue.  Palo Alto Networks customers running Traps are now safeguarded from the Windows CryptoAPI Spoofing vulnerability, regardless of whether they are running an unpatched Microsoft Windows 10 system.


Additionally, Palo Alto Networks offers multiple, additional complementary protections:


As a member of the Microsoft Active Protections Program (MAPP) program, Palo Alto Networks received early details of the vulnerability, providing greater understanding of the threat, which helps us implement strong product coverage.


As always, we recommend keeping your Microsoft products up to date with the latest patches to mitigate this vulnerability.


Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.  CVE-2020-0601: The ChainOfFools/CurveBall Attack Explained POC  Win10 Crypto Vulnerability: Cheating in Elliptic Curve Billiards 2  NSA Cybersecurity Advisory  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


In the months since the WanaCrypt0r/WannaCry and the Petya/NotPetya attacks, security researchers have delved into the nuts and bolts these incidents and the malware involved.


One key thing that research into these security incidents shows is that these attacks used a relatively new and unknown technique called kernel APC attacks as part of their toolkit.


Kernel APC attacks occur in a way that increases the “stealth” factor and makes standard detection and prevention very difficult.


And kernel APC attacks do this while still maximizing the power and control that the code has on the target system.


While kernel APC attacks aren’t well known and can be hard to understand, their proven success in WanaCrypt0r/WannaCry and the Petya/NotPetya make them an important threat to understand because proven attack techniques are quickly adopted widely.


And understanding is a first step to prevention.


To understand what makes kernel APC attacks so dangerous, it’s important to understand what they are.  The kernel is the heart of the operating system.


When talking about operating systems with security permissions and controls like Windows or UNIX/Linux, the kernel operates with the highest level of control.


Because of this, attacks against the kernel are used to gain complete control over a system, generally as part of an “elevation or privilege” (EoP) or “privilege escalation” attack.


Typically, attacks against the kernel are used in conjunction with code execution attacks so that an attacker can target a limited privilege user but ultimately gain full control over the system.


Privilege escalation attacks against the kernel have been around for some time and are well-known and can be well protected against.  Kernel APC attacks however are a different class of attack.


These don’t attack the kernel to gain privileges.


Instead kernel APC attacks already have kernel privileges and use them to further carry out their attack.


In this case by making legitimate programs execute malicious code rather than their own legitimate code.


Kernel APC attacks do this using their control over the kernel to redirect APCs: “Asynchronous Procedure Calls”.


APCs can basically be thought of as places in line for the CPU that the kernel gives access to.


In a kernel APC attack, the attacker gives a legitimate program’s place in line to the attacker’s code.


The crux of what makes this attack technique so important is how the technique uses this level of control to have legitimate programs run illegitimate commands.


It’s easier to detect and prevent illegitimate programs (malware) from executing commands.


But when legitimate programs execute illegitimate commands, it’s harder to detect and prevent: it’s not always clear whether a command is legitimate or not, and interfering with commands from legitimate programs can have significant (sometimes catastrophic) unintended consequences.


And finally because of ways that kernel APC attacks are carried out, it doesn’t leave the usual fingerprints you find after an attack making detection harder still.


Taken altogether, these make kernel APC attacks an effective and sophisticated technique.


And while this technique alone isn’t solely responsible for the damaging power of WanaCrypt0r/WannaCry and Petya/NotPetya it is certainly an important contributing factor.


Perhaps more importantly, it’s a piece of those attacks that has escaped relative notice outside of some specialized parts of the research community.


New effective attack techniques that escape notice are always inviting for other copycat attackers.


A good way to defend against this is to understand and be aware of the thread: forewarned is forearmed.


If you want a more detailed understanding of kernel APC attacks as they occurred in WanaCrypt0r/WannaCry, two good resources are Microsoft’s MMPC blog “WannaCrypt ransomware worm targets out-of-date systems” and Countercept’s “DOUBLEPULSAR Usermode Analysis: Generic Reflective DLL Loader”.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


In recent years, ransomware families are often glamorized as being some of the most dangerous types of malware.


They’ve certainly caused a wealth of damage to end users with some of the more prominent malware families, such as CryptoLocker, CryptoWall, TorrentLocker, and TeslaCrypt infecting millions of users overall.


For readers that might be unfamiliar with ransomware, it’s a type of malware that is responsible for encrypting a user’s files with a key known only to the attackers.


Examples of files that might be encrypted include financial documents, home movies, photos, or business-related files.


In order to decrypt these files, the victim must provide a ransom, or payment, to the attacker, often in the form of a digital currency.


While ransomware is often thought to be bullet-proof, it is certainly not always the case.


In early 2015, Emnisoft identified a new family of malware named PClock.


At the time, the malware was riddled with issues, specifically in the way it encrypted files.


It used a simple XOR encryption routine with a static key, allowing victims to easily recover their files without paying a ransom.


In August, we started detecting updated copies of PClock, which has been improved upon by the malware author.


We set out to determine if this updated version of PClock holds up to some of the more prominent families.


For the sake of clarity, I will refer to this newer version of PClock as PClock2 going forward.


The following sample is used for analysis:  Figure 1.


analysis sample  PClock2 is written in Visual Basic.


For a copy of this file’s IDA Pro database (idb), please refer here.


When initially executed, PClock2 performs a very simple anti-analysis check where it will sleep for a random amount of time and compare the time spent sleeping against a set value.


This check is essentially looking for sandbox systems where the sleep function accelerates analysis.


Figure 2. Check by PClock2 for hooking of sleep function  A simple check is performed to determine if the malware is running with administrative privileges.


Once completed, the malware sends the result via an HTTP POST request to a remote server.


All data sent via HTTP POST requests is sent in the clear.


Figure 3. HTTP POST request containing administrative privileges


The ‘P0’ is statically set by the malware in the above request.


The ‘1828’ represents the thread ID (TID) of the malware, while the ‘rnd’ GET variable is randomly generated.


Throughout the runtime of PClock2, it makes multiple HTTP POST requests to a remote server using the same characteristics, including the ‘PO[TID]’ and the current time.


Additionally, the user-agent used by the entire PClock family, including PClock2, is consistent across samples.


PClock2 proceeds to copy itself with the name “winjab.exe” in the following path.


While this particular sample is seen installing itself to the %ALLUSERSPROFILE% path, other samples have been witnessed using %APPDATA% instead.


PClock2 also enables persistence by setting the following registry key.


All instances of the entire PClock family have been found to use this particular registry key.


After installation is complete, the malware makes another HTTP POST containing the various file paths it used.


Figure 4. HTTP POST request containing file paths of malware  After installation, PClock2 will also set the following registry key with a value of ‘INSTALL_OK’.


This particular registry key is used to hold the latest state of the malware.


Other messages that might be present in this key include the following.


The following registry keys are also used within the CLOCK sub-path by PClock2:  PClock2 proceeds to use the API from blockchain.info to generate a unique Bitcoin (BTC) wallet identifier, which is configured to automatically forward payments to a hardcoded wallet identifier of ‘1MRfkK134ErfbcadUSoSUCBahngCqoBKju’.


The following HTTPS request accomplishes this.


PClock2 will also make a request to the following blockchain.info address to determine the current value of BTC.


This information is stored in the ‘\BData\B’ registry key as previously stated.


The malware proceeds to generate a unique key that will be used in subsequent file encryption using the following data:  This data is concatenated to form a string similar to the following:  Figure 5.


Data collected to be used in formation of unique key  This data is then hashed using the SHA256 algorithm to generate a unique key.


This key is stored in the ‘\CData\C’ registry key as previously stated.


This key is also sent via a HTTP POST request.


Figure 6.


HTTP POST request containing unique SHA256 key  PClock2 scans the file system of the victim in order to identify files that are to be encrypted.


The following paths are ignored:  Additionally, for a list of targeted file types, please see the following link.


Once files are identified, PClock will begin encrypting them, one-by-one.


Unlike the original version of PClock, this variant has forgone the simple XOR encryption routine in place of using RC4.


The RC4 key is generated by concatenating the SHA256 value previously generated with the path to the file being encrypted.


250dd811187959220220574a185ccf669e06c0ee3926773a7cb94750c401812cC:\Documents and Settings\Administrator\Desktop\Form1.cs


It should be noted that PClock takes a very long time to encrypt these files.


On a test sandbox, the malware took upwards of 20 minutes to complete encryption, which is less than ideal for an attacker as it gives the victim time to notice the infection and stop it.


By comparison, the latest version of the CryptoWall malware family takes roughly 1-3 minutes to complete its encryption routine.


It’s also interesting to note that each time PClock2 scans a directory or encrypts a file, it makes an HTTP POST request to the C2 server.


Figure 7. HTTP POST request indicating a folder is being scanned  This resulted in over 1,000 requests being made on a sandbox machine, which contained little data of interest.


After it finished the encryption routine, PClock2 generates a VBScript file in the following directory:


This script file contains the following commands, which will delete shadow copies on the Windows operating system.


Set UAC = CreateObject("Shell.Application") UAC.ShellExecute "vssadmin", "Delete Shadows /All /Quiet", "", "runas", 1  On Windows XP, the following dialog box appears to the victim when this script runs, making it fairly apparent that something suspicious is occurring:  Figure 8.


Dialog box that appears to victim when VBS attempts to run


After running the clean up script the malware overwrites the ‘\CData\C’ registry key with a value of zero, which removes the unique SHA256 key.


Finally, the malware changes the victim’s wallpaper and generates a GUI instructing the victim how they can provide payment and retrieve their files.


This dialogue mimics the more-capable “CryptoLocker” malware family and provides instructions in both English and Spanish.


Figure 9.


Ransom demand


I originally wished to determine if the new version of PClock, PClock 2, included enough improvements to compete with some of the larger ransomware malware families, such as CryptoWall, TeslaCrypt, or TorrentLocker.


In truth, this version has made a number of improvements, such as adding more file types to target, ignoring certain directories, and using a better encryption routine.


However, a number of strong issues still plague this malware family, such as the following:  While this version is an improvement, it still lacks many of the features and stealth that are currently present in the larger ransomware families.


While ransomware is a large problem for users, it’s important to realize that not all malware families are created equal.


Like most things in life, malware comes in many shapes and forms, from the more elegant and robust solutions, to those that come up lacking.


All PClock malware family samples are properly classified as malicious by WildFire.


AutoFocus users can find more information on samples and indicators related to this attack by viewing the PClock tag.