In Part 1 of this series, we laid the foundation of memory corruption exploitation and presented the basic exploitation framework:
This post will cover the implementation of Overwrite and Redirect in the context of stack based buffer overflow vulnerabilities.
Memory Address Space Revisited
In its simplest form, the memory space is divided by the executable code region and the data region. The executable region contains both the program’s unique code as well as the DLLs the operating system provides to all processes. Data region, as its name implies, contains the data on which the code operates. The data region is comprised of the stack and the heap, which we will describe in detail below.
The attacker is interested in the data region since the shellcode by definition will be embedded in what will be loaded to the data region. This means once the file with the shellcode runs, the shellcode resides either in the stack or in the heap.
The Attacker’s Challenge
From the attacker’s perspective, inserting the shellcode to the data region is still far from satisfactory because the shellcode is an executable code. Remember – the shellcode’s role is to be executed and to open a connection between the attacker and the targeted machine. This is the fundamental exploitation challenge:
The shellcode is by default loaded to data region.
The shellcode needs to be executed.
Residing in the data region means that the memory addresses populated by the shellcode will never be fetched to the CPU for execution.
The Attacker’s Solution
The attacker’s main objective is to manipulate the CPU into executing content of memory addresses which under normal circumstances do not get executed. This is wherevulnerabilities come into play.
To recap: when we say that an application has a vulnerability we mean that a crafted input file will cause the execution flow to deviate from its predesignated course. In other words, the CPU is fetched an address it was not meant to receive.
Let’s tie it all together now. The attacker has managed to insert a shellcode to the data region of the process memory, and what it seeks now is a way to get that shellcode executed. To achieve that, the attacker will craft the file in such a way that the deviated address will contain instructions to jump to the shellcode address. Now, the CPU receives an address containing executable code and it will follow the instructions, jump to the shellcode address and execute it.
(Very) Brief Vulnerabilities Overview
Vulnerabilities are tightly related to the overwrite part in the exploitation flow. Different vulnerabilities enable the attacker to overwrite addresses in different parts of the process address space.
The first type of vulnerability we will cover is stack based buffer overflow. This class of vulnerability can be considered a classic exploitation pattern. It is also one of the oldest patterns to be exploited in the wild and is still a prominent part of the current threat landscape.
The Stack
A typical computer program is comprised of a main program and functions or subroutines. When a subroutine is called, it performs its task and returns control to the main program. From the memory address space perspective, the addresses of the main program reside in the code region. When a subroutine is called, a stack is invoked to store its local variables (which roughly correlates to what we refer to as the data). The subroutine then performs its designated task and when it is done, hands over control back to the main program.
From the attacker’s perspective there are three interesting features:
Fixed size: The size of the stack is fixed and determined at the time of the call. For example, let’s assume that the subroutine declared an array of 10 characters. This will be the size of the stack regardless of the arguments we will pass to it.
Return address: The return control mechanism works like this: the stack is invoked with a fixed memory size. Let’s say our 10 characters stack is assigned to address 100. This means that addresses 91 to 100 are assigned to this stack. In addition, address 90 contains the address in the main program to which the CPU should return after the subroutine has fulfilled its task. This memory location is known as the return address.
The stack grows downward: when we provide the actual arguments to the stack, the first goes to the highest address and is then pushed downwards by its followers. So if we provide a 3 character input to our simplified stack, the first one will go to address 100. After that the second one will populate 100 pushing the first to 99. Then the third will go to 100 pushing the second to 99 and the first to 98. Since our input ends here and there are no more arguments, the return address will be fetched to the CPU, which will follow its instructions and jump back to the main program.
Stack Based Buffer Overflow
So far we have described the stack architecture with no malicious context. Now we will explain how this architecture can be maliciously leveraged.
The inherent security flaw in the stack architecture is that it implicitly assumes that the input will match the predesignated size. It works well when the input is either smaller than or identical to this size. The problem arises when the input is larger than the predesignated stack boundaries.
Let’s go back to our simplified stack. Suppose we give the subroutine an input larger than 10 characters. Remember that addresses 91 to 100 are assigned for the input and that address 90 is already populated with the return address. If our input is 11 characters, the first character will go to address 100 and will be pushed downwards. When it reaches 90 it will overwrite the return address. The CPU will try to follow the instructions in address 90 but because they do not exist anymore, it will break the execution flow and the process will crash. This is known as Stack Overflow.
Let’s also remember that the shellcode resides in the stack and the attacker attempts to cause it to be executed.
In order to leverage stack overflow for its purposes, the attacker will craft the subroutine input in a way that the return address will be overwritten with new instructions which will redirect the CPU to the shellcode location.
In our simplified stack example, the attacker will craft an 11 character size input. The shellcode resides in characters 11 and 10. Character 1 contains instructions to jump to 11 and execute. In that case when the subroutine is called, character 1 will be pushed down, overwrite the return address and redirect the CPU to address 100 where the shellcode is. The CPU will blindly follow the instructions and execute the shellcode.
Zoom Out on Exploitation Architecture
As you can see in our example above, the exploitation parts are not connected to each other: embedding a shellcode is totally decoupled from crafting the input file to trigger a certain vulnerability. The triggered vulnerability enables the return address to be overwritten. The instructions, which overwrite the return address, redirect the CPU to the shellcode but other than do not relate to the shellcode’s functionalities in any way.
The art of exploits is to orchestrate these independent parts to work together. In a similar way, the art of protection against exploits is to obstruct either the independent parts directly or the orchestration among them.
Conclusion
We have learned how the basic exploitation framework is implemented on stack based buffer overflows vulnerabilities. Despite its age (the earliest documented attack was the Morris Wormin 1988), this class is still a prominent part of the threat landscape. We encounter exploitations of these vulnerabilities in various readers, players and Microsoft office documents but also in industrial protocols and services.
In the next Exploitation Demystified post, we’ll cover implementation of the exploitation framework on heap-based vulnerabilities.
In 2015, the cybersecurity market witnessed the introduction of a slew of new and improved products that promised to enhance the detection and response capabilities of organizations against malware. The prevailing rationale was that an improvement in these tools would help organizations to reduce the impact of malware by becoming better at spotting suspicious activity. Unfortunately, the threat agents also witnessed this trend. Their attacks became more targeted, oftentimes uniquely designed to compromise a given organization’s defenses.
The shift from executable malware to exploits will continue
In 2016, we can expect that well-funded, highly skilled, and patient threat agents will shift their focus toward deploying the types of attacks that are virtually undetectable by current antivirus solutions and much harder to counter by current “detect and respond” tools. These attacks will exploit vulnerabilities in legacy and commonly used applications that are often whitelisted or play a major role in the organization’s business processes; hence, these applications cannot be eliminated without having a negative impact on the organization’s ability to conduct business.
As threat actors become more effective in the reconnaissance of their targets, the exploits will become more highly customized to the specific applications in use by a target organization, and even to the targeted individuals within that organization.
In 2016, software developers will undoubtedly continue to improve the overall security of their applications and operating systems, while threat actors will escalate the perpetual “cops and robbers” game by deploying exploits that are more sophisticated – and often created by professional exploit developers.
Organizations will realize the futility of fighting machines with people
Cyberattacks in 2015 exhibit a massive increase in volume, velocity and variation. The fundamentally asymmetrical nature of cyberattacks, in the sense that small groups of highly skilled individuals have the potential to inflict disproportionately large amounts of damage on an organization, took a turn for the worse as attackers gained increased access to more scalable options, such as Malware-as-a-Service and Exploits-as-a-Service.
While attackers unleashed an army of machines on their targets with a click of a mouse, many organizations continued to commit their scarce resources to the perpetual loop of “detect and respond,” which is to identify, investigate, remediate, recover, and then repeat.
In 2016, we can expect that organizations will finally realize this people-intensive approach is no longer scalable or sustainable. Organizations will recognize that automation and scalability are the keys to matching the asymmetric nature of cyberattacks. And they will come to rely on new tools that can effectively prevent the army of machines from using sophisticated and previously unknown threats, malware, and exploits to compromise the organization’s defenses.
The pendulum will start to swing back from detection and response toward prevention
2015 witnessed the continuing market sentiment that security breaches are inevitable, that organizations should assume a breach has already happened, and that the best course of action is to focus scarce resources on rapid detection and response in order to minimize the impact.
Despite the proliferation of new services and products that focused on helping organizations to improve their ability to detect and respond to malicious activities, organizations will realize that these advancements cannot change the economics of their chosen approach.
The fact remains that the further along the breach continuum one detects and intercepts an attack, the higher the negative impact, and the costlier it will be to recover and remediate.
In 2016, organizations will begin to realize that breach prevention is not only possible but also more viable and sustainable. Although detection and response capabilities will remain necessary for a balanced security posture, the old adage “an ounce of prevention is worth a pound of cure” will resonate with more and more organizations.
Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.
If you’ve been to any recent Palo Alto Networks Ignite conferences, you’ve likely attended sessions led by our Product Management team on best practices for various Palo Alto Networks technologies and security initiatives.
Actually, those best practices sessions are, by far, our most requested and well-attended sessions. Customers have been very interested in how technologies on our platform can be combined to improve their security posture and make their lives easier. As one of my customers once put it, “Your platform is like a Swiss Army knife. There are all these cool tools and features, and you just have to figure out how to combine them to solve the problem at hand.”
For instance:
Combine SSL decryption and URL Filtering to easily identify URL categories for decryption and inspection.
Combine URL Filtering and file blocking to disallow .exe downloads from high-risk URL categories, such as dynamic-DNS or unknown URLs.
Combine App-ID, User-ID, and Content-ID technologies to identify known versus unknown users, restrict their access to applications housing sensitive data, and enforce strict decryption and threat inspection policies. This combination will make sure that unknown users are not doing anything malicious to your network.
Combine User-ID and file blocking to help prevent the delivery of malware via watering hole or a spear phishing attack to groups of users who don’t have a business reason for downloading Portable Executable (PE) files types, such as .exe, .dll, and .scr.
Over the years, we have accumulated tons of tips and tricks throughout our tens of thousands of customer engagements that we actively recommend to our customer base. We are still discovering new ways our customers combine and use features on our platform to solve their problems.
Here are just a few of these recommendations:
Enable file blocking profiles within your application-based policies and allow only certain file types to be downloaded or uploaded to prevent malware downloads and data exfiltration.
Utilize the dynamic block list feature on the NGFW to prevent traffic to and from known malicious IPs. Or, better yet, copy the IP addresses that have triggered a number of IPS signatures in a certain amount of time, and paste them into a dynamic block list to help prevent attacks from actively targeting your organization.
Enable DNS sinkhole functionality on the NGFW to provide your security and IR teams with a list of users and endpoints actively attempting to connect to command-and-control domains, as they’ve very likely been compromised. The sinkhole will block the communication and provide a high fidelity list of users for whom you should probably re-image devices.
Alert on or disallow SSL traffic over unexpected ports, especially if it’s traffic you aren’t able to decrypt and fully inspect for threats.
Activate strict threat profiles for Threat Prevention signature sets (IPS, AV, anti-CnC) and leverage WildFire to configure signature updates every 15 minutes within your data center to help prevent lateral movement on east-west traffic and data exfiltration.
We use tips like these to help our customers better secure their organizations and more fully leverage technology and features within the Palo Alto Networks Next-Generation Security Platform. For us, it’s all about enabling business and preventing breaches.
That’s why we’re collecting these tips, tricks, and tactics and publishing them in a series of chapters – our recommended best practices. The first chapter, on leveraging application-based policies to provide complete visibility (the first step in reducing the attack surface), is available now within our Fuel community and will be followed by chapters on decryption and user-based policies in the next few weeks.
Be sure to download our best practices to find out how you can better secure your organization or confirm that you’re already ahead of the game.
Unit 42 recently published a blog on a newly identified Trojan called Bookworm, which discussed the architecture and capabilities of the malware and alluded to Thailand being the focus of the threat actors’ campaigns.
In this blog, we will discuss the current attack campaign along with the associated threat infrastructure and the actor’s tactics, techniques and procedures (TTPs). The following list provides a summary of the threat actors TTPs, which we will cover in this blog:
Actively attacking targets in Thailand, specifically government entities.
Uses Bookworm Trojan as the payload in attacks.
Has access to compromised servers that they use to download Bookworm.
Known to use spear-phishing as the attack vector to compromise targets, but have access to compromised web servers that could facilitate strategic web compromise (SWC) as an attack vector in the future.
Uses standalone Flash Player to play slideshows that contain pictures of current events in Thailand as decoy documents, but also use the legitimate Flash Player installation application as a decoy in some instances.
Uses date codes to track campaigns or Trojan version. If date codes are indeed used for campaign identifiers, then the dates precede attacks or current event seen in decoys by 6 to 18 days, which provides a glimpse into the development and operational tempo of this group.
Use of large command and control (C2) infrastructure, which heavily favors dynamic DNS domains for C2 servers.
Deployed Poison Ivy, PlugX, FFRAT and Scieron malware families.
Bookworm Attack Campaign
Threat actors have delivered Bookworm as a payload in attacks on targets in Thailand. Readers who are interested in this campaign should start with our first blog that lays out the overall functionality of the malware and introduces its many components.
Unit 42 does not have detailed targeting information for all known Bookworm samples, but we are aware of attempted attacks on at least two branches of government in Thailand. We speculate that other attacks delivering Bookworm were also targeting organizations in Thailand based on the contents of the associated decoys documents, as well as several of the dynamic DNS domain names used to host C2 servers that contain the words “Thai” or “Thailand”. Analysis of compromised systems seen communicating with Bookworm C2 servers also confirms our speculation on targeting with a majority of systems existing within Thailand.
Static Date Codes and Decoys
As mentioned in our previous blog on Bookworm, the Trojan sends a static date string to the C2 server that we referred to as a campaign code. We believed that the actors would use this date code to track their attack campaigns; however, after continued analysis of the malware, we think these static dates could also be a build identifier for the Trojan. It is difficult to determine the exact purpose of these static date codes with our current data set, but we will cover both possibilities in the next sections. While we currently favor the theory that these dates act as campaign codes, we extracted the following unique date codes from all known Bookworm that suggests the threat actors began their campaign in June or July 2015:
20150626
20150716
20150801
20150818
20150905
20150920
Trojan Build Dates
Threat actors may use the date string hardcoded into each Bookworm sample as a build identifier. A Trojan sending a build identifier to its C2 server is quite common, as it notifies the threat actors of the specific version of the Trojan in which they are interacting. As mentioned in our previous blog, Bookworm is fairly complex based on its modular framework, which suggests that the threat actors would need to know the exact version of the Trojan they are communicating with in order to install appropriate supplemental modules.
While a plausible premise, our data set does not fully support the hardcoded dates in Bookworm samples as a build identifier. To attempt to confirm the dates acting as a build ID, we extracted all of the modules for each Bookworm sample. We then compared the modules of each Bookworm sample that had the same date values. Most of the modules were identical amongst Bookworm samples using the same date string, but several samples had differing modules yet the same date string. For instance, Table 1 shows two sets of Bookworm samples with the “20150716” and “20150818” date codes that have completely different Leader.dll modules.
Date Code
Leader.dll Module
Compile Date
20150716
e602a12e8173ca17ba4a0c6c12a094c1
2015-07-18
20150716
4537257cb69a467a63c5a561825571f9
2015-07-23
20150818
e6cb32805bc5d758a5ea1dcd3c05beb8
2015-08-24
20150818
7065c709dd9dc7072dd5a5e2904c2d78
2015-08-31
Table 1 Two sets of Bookworm samples that share a sttic date cod but have different Leader modules
If the Bookworm developers used the date code as a build identifier, it would suggest that a new date code would have been added to samples using the new Leader module. Due to these changes without a new date string, we believe the date codes are used for campaign tracking rather than a Bookworm build identifier. Unit 42 will continue to compare the date codes to the Bookworm modules in future samples and will modify our assessment if indications suggest the date string is indeed a build identifier.
Campaign Codes
We believe that Bookworm samples use the static date string as campaign codes, which we used to determine the approximate date of each attack that we did not have detailed targeting information. We also compared these campaign codes to the date the attacks occurred or the date of the event seen in decoy documents to get a sense of the threat group’s internal operations.
A number of the Bookworm samples include a decoy that is opened during installation of the malware in an attempt to disguise the compromise. The threat actors have used two types of decoys thus far: a legitimate Flash Player installation application and a standalone Flash application to display a photo slideshow. The use of a Flash Player installer, seen in Figure 1, suggests that the threat actors are using social engineering to instruct the victim to update or install the Flash Player application. The Bookworm campaign code “20150818” was used in all samples associated with these legitimate Flash Player installers.
Figure 1 Adobe Flash Player Installer used as a Decoy
Unit 42 has witnessed six decoy slideshows used in a Bookworm campaign targeting Thailand. All six of these decoy slideshows contain pictures that in some manner relate to Thailand. One known decoy includes an animation of what appears to be children in Thailand going to temple (Figure 2), which is associated with a spear-phishing attack on a branch of the Thailand government that occurred on July 27, 2015. The decoy’s filename is “wankaophansa.exe” that suggests the animation is regarding Wan Kao Phansa, which is a term for first day of the three month long rainy season. Wan Kao Phansa is a national holiday in Thailand, which in 2015 started on July 31. The attack occurred four days before the actual holiday and had a campaign code of “20150716”, which is eleven days before the attack took place.
Figure 2 Decoy slideshow of children in Thailand celebrating Wan Kao Phansa or Buddhist Lent
We do not have detailed targeting information on the attacks that delivered the remaining five decoy slideshows. To determine the approximate date of these attacks, we compared the Bookworm campaign code associated with each decoy slideshow and found that they coincide with the timeline of events seen in the photos in the decoy slideshows.
Three of the decoys analyzed are related to the August 17, 2015 bombing near the Erawan Shrine in Bangkok, Thailand, as seen in Figures 3, 4 and 5. The campaign code “20150801” is associated with the decoy slideshow showing the graphic Erawan Shrine bombing (Figure 3), which is 16 days before to the actual event took place.
The second bombing-related decoy, seen in Figure 4 contained pictures of the arrest of a bombing suspect named Adem Karadag. This arrest was made on August 29, 2015, which is 11 days after the campaign code “20150818” that was associated with the decoy slideshow.
Figure 4 Picture from a Decoy Slideshow Showing the Arrest of a Bomber Related to the Erawan Shrine Bombing in Bangkok, Thailand
The third and final bombing-related decoy slideshow contains pictures of Adem Karadag re-enacting his role in the bombing for police (Figure 5). This re-enactment is a standard procedure for Thai police, which in this particular case took place on September 26, 2015. The campaign code “20150920” is associated with this decoy, which is six days before the actual event took place.
Figure 5 Picture from Decoy Slideshow of Erawan Shrine Bombing Suspect at the Crime Scene
Another decoy slideshow associated with the Bookworm attack campaign contains photos of an event called Bike for Dad 2015. Bike for Dad is a cycling event that will be held on December 11, 2015 to commemorate the King of Thailand Bhumibol Adulyadej’s 88th birthday. Many high profile figures in Thailand are promoting this event, such as the Prime Minister Prayut Chan-o-cha who is seen in many of images in the decoy slideshow (Figure 6).
The campaign code “20150920” is associated with this decoy, which is a week prior to media articles announcing that the Crown Price of Thailand Maha Vajiralongkorn will lead the Bike for Dad 2015 event. At first, we believed the use of the Bike for Dad 2015 event was unrelated to the previous Erawin Shine bombing decoys. According to the same announcement article, the Crown Prince said that the bike route would pass the Ratchaprasong intersection, which is where the Erawin Shine bombing took place. Therefore, the threat actors using this within their social engineering attempts continues to follow the theme involving the bombing of the shrine in Bangkok, as it is undoubtedly still in the hearts and minds of the Thai people.
The final remaining known decoy includes photos of Chitpas Tant Kridakon (Figure 7), who is known as heiress to the largest brewery in Thailand. Chitpas is heavily involved with Thailand politics and was a core leader of the People’s Committee for Absolute Democracy (PCAD), which is an organization that staged anti-government campaigns in 2013 and 2014. As recently as September 2015, Chitpas has been in the news for her attempts to become an officer in the Royal Thai Police force, which has caused protests due to her political stance. Two of the images in the slideshow can be seen in an article that was published on September 20, 2015. These images were associated with the Bookworm campaign code “20150905”.
Figure 7 Picture of Chitpas Tant Kridakon included in a Decoy Slideshow
By comparing the campaign codes with the dates of known attacks or the date of the events shown in the decoys, we found that the campaign codes precede the attack or event dates by 6 to 18 days. The campaign code date preceding the attack or associated events suggests that the threat actors perform development operations on their tools and then choose their decoy. These decoy documents also suggest that the threat actors actively track current news events and use photographs from the media to create their decoy slideshows.
Compromised Hosts
Unit 42 analyzed the systems communicating with the Bookworm C2 domains and found that a majority of the IP addresses existed within autonomous systems (ASN) located in Thailand. The pie chart in Figure 8 shows that the vast majority (73%) of the hosts are geographically located in Thailand, which matches the known targeting of this threat group. We believe that the IP addresses from Canada, Russia and Norway are analysis systems of antivirus companies or security researchers. The IP addresses in South Korea prove interesting and could suggest that this threat group has carried out an attack campaign on targets in locale as well. However, we’ve found no additional evidence to corroborate this theory.
Figure 8 The Unique IP Addresses Seen Communicating with Bookworm C2 Emphasizes Attacks on Targets in Thailand
We took the IP addresses seen communicating with Bookworm C2 servers and obtained their geographic coordinates using an IP geolocation database and plotted them on a map, as seen in Figure 9. A majority of the IP addresses in Thailand have coordinates in the Bangkok metropolitan area, with one in the southern town of Pattini and one in the Phanat Nikhom District of the Chonburi Province. IP geolocation systems are not perfectly accurate, but the data suggests that most of the compromised hosts exist near the largest city of Bangkok. This grouping of compromised hosts also aligns with the known targeting, as Bangkok and Nonthaburi is where a majority of the government of Thailand exists.
Figure 9 Map Showing GeoIP Locations of Compromised Hosts Grouped in the Bangkok Metropolitan Area
Bookworm’s Threat Infrastructure
Bookworm-related infrastructure created by threat actors mainly involves the use of dynamic domains, however, an early sample used a fully qualified domain name (FQDN) owned by the actor. The actors also appear to have access to legitimate servers that they use to host Bookworm and other related tools for attacks. Overall, the Bookworm infrastructure overlaps with the infrastructure hosting C2 servers used by various attack tools, including FFRAT, Poison Ivy, PlugX, and others.
Compromised Web Servers
Unit 42 has seen threat actors hosting Bookworm and other related tools on legitimate websites, which suggests the actors have unauthorized access to these servers. We have witnessed Bookworm samples hosted on a website belonging to the following organizations:
Two branches of government in Thailand
Thai Military
A Taiwanese Labor Association
Three of the four compromised webservers have been breached in the past with each being listed on Zone-h as being defaced, while the remaining site was defaced by the TURKHACKTEAM, according to a Google cache from November 11, 2015. The specific details of how the actors gained access to these sites is unclear, however, one site has a publicly accessible form that would allow visitors to upload files to the webserver (Figure 8). Unit 42 believes that threat actors could have uploaded Bookworm to this server using this form. It is also possible that the threat actors uploaded an ASP shell to gain further control over this webserver. We also speculate that these threat actors may use strategic web compromises (SWC) as an attack vector in future campaigns using their unauthorized access to webservers.
Figure 10 Publicly Accessible Form to Upload Files to Server Seen Hosting Bookworm Trojan
The site hosting this file upload form belongs to one of the organizations targeted with Bookworm. This may suggest that the threat actors used this webserver to pivot from the webserver into the internal network.
Infrastructure Overlap and Related Tools
The domains hosting Bookworm C2 servers (see Indicators of Compromise section of ourBookworm blog) connect to a larger infrastructure that the threat actors are using to host C2 servers for other tools in their toolset. So far, Unit 42 has seen infrastructure overlaps with servers hosting C2 servers for samples of the FFRAT, PlugX, Poison Ivy and Scieron Trojans, suggesting that the threat actors use these tools as the payload in their attacks.
Unit 42 enumerated the threat infrastructure related to Bookworm and created a chart to visualize connected entities to its current attack campaign. The infrastructure is fairly complex and has many overlaps with other toolsets. Figure 11 below shows a fraction of the threat infrastructure that visualizes a connection between Bookworm, FFRAT, PlugX and Poison Ivy.
Figure 11 Infrastructure Overlaps connecting Bookworm to samples of the PlugX, Poison Ivy and FFRAT Trojans
The overlap between Bookworm, PlugX and Poison Ivy samples involves the use of the Smart Installer Maker, which is a common technique used by this threat group. In one particular case, a sample of the Smart Installer Maker (MD5: 6741ad202dcef693dceb98b0a10c49fc) installed both a PlugX and Poison Ivy Trojan that communicated with domains that resolved to an IP address (119.205.158.70) that also resolved a Bookworm C2 domain (sswmail.gotdns[.]com). This IP address was also used to resolve a domain (qemail.gotdns[.]com) that actors used to host a C2 server for another Trojan known as FFRAT. We observed another direct overlap in a C2 domain (ubuntudns.sytes[.]net) used for both Bookworm and FFRAT.
As previously mentioned, the infrastructure related to Bookworm is fairly complex with many connections to domains hosting C2 servers for other tools. The related infrastructure and associated malware can be seen in the table below.
We made connections between domains seen in Table 2 through shared stolen code signing certificates, other PE build commonalities, passive DNS data and direct C2 domain overlap. The domains connected using passive DNS all share common IP addresses used to resolve the domain. The following IP addresses provided many of the connection points within the infrastructure via passive DNS overlap:
226.127.47
156.239.105
167.143.179
144.107.22
144.107.46
144.107.52
144.107.53
144.107.134
144.166.209
205.158.70
248.8.249
Conclusion
Threat actors have targeted the government of Thailand and delivered the newly discovered Bookworm Trojan since July 2015. The actors appear to follow a set playbook, as the observed TTPs are fairly static within each attack in this campaign. The threat actors have continually used Flash Player installers and Flash slideshows for decoys. The decoy slideshows all contain photos from very meaningful events to individuals in Thailand, suggesting that the actors continually look for impactful events to use to disguise their attacks.
The vast majority of systems communicating with Bookworm C2 servers are within the Bangkok metropolitan area where a majority of the government of Thailand exists. While the current campaign has targeted the Thai government, Unit 42 believes the threat actors will target other governments to deliver Bookworm in future campaigns.
Nexon Asia Pacific, a Palo Alto Networks Managed Security Service Provider (MSSP), has about 120 staff across offices in Sydney, Melbourne and Brisbane. The Australia-based company covers about 200 enterprise clients, offering managed networking, telephony, and in recent years, cloud and application services. What Nexon sought — and found with Palo Alto Networks — was a way to manage security for the full stack of those services across one platform.
“We literally had four separate devices providing the security solutions that we were offering to our customers and the Palo Alto Networks platform gave us the ability to integrate all of those platforms into one and provide one source of reporting and visibility into the platform,” noted Barry Assaf, Nexon Asia Pacific director, in a recent interview with The Australian.
We invite you to read some recent coverage of Nexon Asia Pacific and Palo Alto Networks, including in CRN Australia and Channel Life, as well as the case study. And while you’re at it,come to our Customers page to read more stories and learn about businesses all over the world that have embraced the Palo Alto Networks next-generation security platform.
