CyberWire Daily - Pacifier APT : Bitdefender's Liviu Arsene describes a sophisticated, multifaceted malware campaign. [Research Saturday]

Episode Date: September 23, 2017

In 2016 Bitdefender uncovered a new advanced persistent threat dubbed Pacifier, targeting government institutions starting in 2014. Using malicious .doc documents and .zip files distributed via spear phishing e-mails, attackers would lure victims with invitations to social functions or conferences into executing the attachments. It’s capable of dropping multi-stage backdoors. Liviu Arsene is a senior e-threat analyst at BitDefender, and he's our guide to the complex components of Pacifier APT. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. About a year ago, we uncovered a very, very interesting and advanced piece of malware targeting specific individuals in a very interesting way. That's Lidiu Arsini. He's a senior e-threat analyst for Bitdefender. He and his team uncovered a new advanced persistent threat that they call Pacifier. At that point, we only uncovered part of the attack or part of the malware, as it were. Now we followed up on that investigation. And in this report, we actually have three new components were actually modules that are actually dropped by the same by the same APT. We call it pacifier APT.

So let's start with some attribution. You all are saying that this is coming from the Turla Group. Tell us about them. When we started the investigation about a year ago, we didn't know actually who might have been behind the attack. But as we came up with the investigation and we published the report, other security researchers in the industry started to do their own investigations and found that the same module that we analyzed was actually used in another series of campaigns attributed to the Trula Group. So the Trula Group actually believed to be backed up by the Russian government, working for the Russian government. So that's how the whole idea got fed into this grinder, if you will, that the entire APT pacifier campaign is backed up by the Trula Group. So give us an overview. What's involved with the APT pacifier campaign is backed up by the Twila Group. So give us an overview. What's involved with the APT pacifier? What we know is that it's a very complex, very well-written, very complex and modular

piece of malware designed to exfiltrate data for a very long time and remain persistent without triggering any suspicion from traditional security mechanisms. For example, in this new paper that we published, we have three new modules that have three different ways of exfiltrating data while remaining completely undetected in the process. So one of these modules is actually a traditional binary file. And what's interesting about that is that it can broadcast information from a non-Internet-connected computer to the Internet, to the attacker. It does that by it knows in advance how the internal network topography of the victim looks like, and it has a hard-coded IP address of the local Internet computer that has Internet access.

So once the non-Internet-connected computer victim is infected, data is exfiltrated through the Internet connected computer over the local network, and then it reaches the attacker. Let's go through them one at a time. I mean, this first backdoor, it seems to be a way around air gap systems. Let's dig into some of the details here. First of all, how does it get the topography of that local network ahead of time? That is a very interesting question. We didn't know that until we analyzed the third backdoor, the third module that I'm about to discuss right now. That third component is what we believe to be responsible for gathering intelligence from the victim.

It's actually a component, pretty much a simple script. It's a basic script that executes a series of common Windows commands and then runs through a series or a list of command and control addresses and broadcasts the information it collects from those commands. It's kind of like running a command line with the instructions on giving you system information about the current computer and then broadcast that information to the attacker. So the attacker would know what operating system you're using, what's the internal IP address of your LAN network, of your local network, what's your DHA server, and stuff like that.

So it's basically just system information that's practically used for data reconnaissance. So let's go through each of these components one by one. The first section you label no internet, there's a back door for that. And this is the one that can compromise air gap systems. Share with us some of the details on that one. Well, the module was designed to specifically spread using USB devices. So once it detected a USB flash drive, it created a hidden folder, if you will,

and then it piggybacked its way onto one computer to another until it reached its victim. Once it did that, it was programmed to exfiltrate specific pieces of information, and because it had prior knowledge, it had been priorly coded with the internal network's topography, it knew exactly which computer from within the local network to contact in order to get that information from the non-Internet connected computer

to the attackers over the Internet. And what was the initial vector for infection? Well, we believe that they were all dropped by the same dropper that we analyzed about a year ago, also known as Skipper, as some other security researcher have named it. So all of these modules can actually be downloaded either all at the same time or separately, depending on what the threat actor's intent is.

So if they want just to download the reconnaissance component after the original spear phishing email has been sent, they can just do that. If they want to download additional tools, they can do that as well. For example, besides these three modules that we've analyzed, there are also some open source free tools that have been downloaded by attackers on the victim's computer, specifically to perform reconnaissance actions or forensic actions, like dumping a process's memory or performing man-in-the-middle attacks on browsers. You know, they were able to intercept

encrypted and non-encrypted browser network traffic communication. And again, these are all open source tools that were probably downloaded after the original infection point. And this system uses a fairly sophisticated communication systems between the target computer, the air gap computer, and the computer on the LAN that's connected to the internet. Well, it's not necessarily a very sophisticated communication system between these two computers, but the fact that it had prior knowledge of what that internet computer was, that's the interesting part, because that demonstrates the attackers actually knew

precisely how the internal network of the victim looks like and how to exploit it at its finest. The second part is the transport module. This transport module is just a subsection of this data exhibition, of this first trojan that we analyzed. So during the technical analysis, we broke down each Trojan into separate modules and how they operate. I see. The three main Trojans are basically this one

that connects a non-internet connected computer to the internet. There's the second one that is a visual basic script. And there's the third one that was used for reconnaissance, for collecting information about the Trojans. I see. So let's move on to the second one, using the browser cache to evade security. This is a fairly novel system here.

This is actually something very interesting, and I personally haven't seen it in the wild up to now. If I'm mistaken, probably I'll get a lot of hurt from that from other security researchers, but I personally haven't seen it used ever before. Why? Well, the reason for that is simple. Using the browser's cache mechanism is a legitimate action. It's the way browsers are supposed to work. Whenever you connect to a browser, to a homepage, for example, you download components from that webpage, especially if you are connecting to it for the first time. download components from that web page, especially if you are connecting to it for the first time.

If you are connecting to it for a second time or a third time, the browser automatically knows that you have previously visited that web page and you don't have to download all the components because it already has a couple of images or Cascade style sheets already saved in a temporary folder. So that's the way the browser caching mechanism works. What attackers did in this case is they developed a visual basic script, which is pretty much

is a script. It's not a binary. It's usually not scanned by traditional security solutions. So it can pass by undetected. A script is basically a series of commands that are executed. So they devised a visual basic script that changes the homepage address of Internet Explorer. It changes that address to a legitimate website. So each time a user would open Internet Explorer, again, that would mean that the attackers had prior knowledge that their victim would often use Internet Explorer. So when the user opens Internet Explorer,

he will be redirected automatically to that legitimate website. However, that legitimate website would contain a JavaScript. It's not uncommon for websites to use JavaScript. They do all sorts of interesting stuff, magic stuff. It's really cool. However, this JavaScript was not meant to be there. So this JavaScript was actually added by the attackers on a legitimate website. How they did that, it's probably by exploiting

a vulnerability in the website, and they simply placed it there so that whenever a victim connects to the website, they can relay commands through that JavaScript to the browser, to the victim's browser, ultimately saving those commands in the cache, in the browser's cache. So those commands are actually translated from the website's JavaScript to the browser's local cache, where they get stored. Fine and dandy up until now. There's practically no hint of a warning. There's practically no malicious behavior whatsoever up until this point. It's practically normal behavior. Okay, the interesting thing happens when the same visual basic script that altered the homepage of Internet Explorer starts at random intervals to check the browser's memory cache for files containing specific instructions for a specific

syntax. At random intervals, it doesn't matter. Whenever it finds a file containing commands, it starts executing them, and the output gets saved in the same local cache, in the same browser's local cache. Now, this is where I'm going to pause for a second because the real kicker is attackers usually want access to information as fast as possible.

They want to get in and out in a matter of seconds, hours, days, it doesn't matter, but they want continuous access to that information. Now, the kicker is that once those malicious commands were executed and the output was saved in the browser's cache, it didn't get broadcasted immediately. Actually, it was the user inadvertently broadcasting the information to the attacker. Why? Well, because activating or opening Internet Explorer again, it would make the victim connect to the same website hosting the malicious JavaScript.

So that in turn would force the browser's cache, so the local cache, to be broadcasted to the website, to the malicious website, and in turn relay that information to the attackers. broadcasted to the website, to the malicious website, and in turn relay that information to the attackers. So it's kind of like using the user's own habits against him without leaving any footprint. So the attackers would never have gained access to the user's information unless the user would have opened again Internet Explorer, which is pretty interesting because that's the novelty

of it all. Using the browser's cache and actually relying on the user's behavior to gain information from him without compromising your persistence on the system. Because usually, when a piece of malware wants to exfiltrate information, it starts making up its own connections with the command and control server. It starts its own processes,

it starts to random IP addresses. Usually, you can spot these kind of activities. But when you're using the browser, typically local cache, and you're using a legitimate website to do so, it raises absolutely no suspicion whatsoever. So is there anything you can do within, say, Internet Explorer to disable the execution of a Visual Basic script?

Well, the execution of the Visual Basic script can only be prevented if you delete the registry key. So if you delete that registry key, practically you stop the entire process. But that's not something someone would know to do. And this is all happening behind the scenes. And again, there's no indication that anything is out of the ordinary. Absolutely. The average user would not know anything is wrong. Plus, traditional security solutions are not designed to scan for registry keys. I mean, they do check for malware that tries to run at startup by creating a registry key, but they don't usually

scan the contents of that registry key, or they don't scan the contents of the visual basic script. Just like I mentioned earlier, a visual basic script is just a series of commands. It's like typing in command line ping google.com. It's that simple. So what kind of information are they looking to get from the victims? Well, it's difficult to tell because there's no way of actually knowing what they actually managed to get a hold of or what they were interested in finding out. By deploying these tools, these modules, they were able to gain access to content from browsers, from Microsoft Outlook, or other usually business-related applications. And is there, in the communications between the system and the command and control server,

is that communication encrypted? Well, the funny part is, in some modules, yes, and in others, it isn't. For example, the third module, the one that is responsible for gaining information about the victim's computer, the one that is simple enough, the communication seems to be unencrypted. It uses plain HTTP, no encryption whatsoever. Because apparently the attackers weren't concerned, I'm assuming, that they weren't concerned that system information would be something that important to be encrypted.

Even if you were able to scan HTTP, you would only find system information and that's it. There would be no actual classified information or sensitive information that you would consider to be of importance. So let's go through that third component. This is victim profiling with a JavaScript backdoor. Take us through how this part works. The JavaScript backdoor is a pretty obfuscated script, but it had a very, very simple purpose. Its purpose was to execute a series of commands designed to gain or collect as much information as possible about the victim's computer and the network it's connected to, it's attached to. For example, it would gain information about what type of operating system the victim has, what Internet Explorer version they run, what type of subnet IP address they have, and so on. So all of this information was practically broadcast into a list of command and control

servers that the script would just parse through, and all of that information would be sent unencrypted in plain text, and that's it. At some point, it would repeat the process to see whether or not any of that information has changed, but that would only happen at random intervals. There was no timer set to it. There was no timer in terms of every day, every hour, every 30 minutes. It was a random interval.

That script would activate and send that information. So I think one of the things, as you mentioned earlier, that's interesting is that these folks seem to have an unusual amount of patience. Exactly. Not just an unusual amount of patience, but they're also very focused. They know exactly how the victim behaves. They know exactly what tools they use, and they are very skilled at implementing new techniques. For example, these three modules have different functions, they have different behavior, they have been coded differently, they look completely different, and they use three separate communication channels, three separate communication methods, if you will. They seem to be highly versed and highly skilled at what they're doing.

And how did these initially come to your attention? Well, the investigation started about a year ago when we uncovered the original, the first component that we dubbed Pacifier. That was spread through a series of phishing emails designed to exploit a vulnerability in Microsoft Office. And then we caught our attention when the vulnerability downloaded a dropper, a malicious payload. And when we analyzed that dropper, we figured that at some point, some additional modules might be downloaded because that dropper had the capability of doing so. Naturally, we came out and published that paper, and we

continued our investigation and found these new components. What's your sense for how widespread this is? Is this only hitting, is this a highly targeted attack, or is this something that regular folks need to be concerned about? Judging by the way these modules operate, it seems to be a highly targeted and very specific attack. Just like I mentioned earlier, the fact that one of the modules knew exactly which computer to connect to within the local network to broadcast information, or the fact that they knew that the user would ultimately use Internet Explorer, or the fact that they knew that the user would probably open Internet Explorer at least a couple of times a day. So they would have to be patient and not necessarily force a connection to the command and control server. As a result of learning what you have about these attacks, what sort of advice do you have for people in terms of protecting themselves

against this sort of thing? Well, it's difficult to give you a specific advice on how to protect yourself. There are a general set of rules, best practices that you can do, that you can adhere to, for example. You can try not to open email attachments from untrusted sources or not double-click any URLs that you receive in emails. For example, if you receive an email, if you work in a front desk and you receive an email saying, check out the attached invoice, you naturally get the impulse, the urge to double-click the attachment. But take a while, take a second or two to look at the email address that sent you the attachment. Try to figure out whether or not that might be or might not be an efficient email.

Secondly, try to at least have a security solution installed. Some security solutions are great at preventing or blocking attacks at some steps during the attack chain so that at least will prevent the attacker from going further with the attack or block the attacker completely as soon as he tries to gain access to your computer. And first, the best advice I can give you is never trust everything that you read. Never trust everything you read. Go on. Never trust everything that you read in terms of emails that you get

that sound too interesting, too preposterous, too alluring. Never click on URLs that you have never visited before. Never buy stuff from websites that you have never heard about. So caution is always the best advice

in terms of security. But in terms of security. But in terms of automated scanning systems, a virus protection sort of thing, I mean, this system would have flown under the radar of all those sort of systems, yes? Well, it is possible. I mean, just like I mentioned earlier, a security solution has multiple layers of security defenses. So it stands to reason that one of those layers would have prevented the attack during at least one of these phases. For example, it might not have prevented the original dropper from being executed, but it might have prevented one additional module from being downloaded from the Internet. downloaded from the internet. So whenever the attacker would have tried to download an additional component, probably the antivirus solution or the security solution would have stepped in and said,

hey, you're not supposed to download this file. This is a binary file. We don't trust it. Lock it. And then some suspicions might have been raised. Our thanks to Lidiu Arsini from Bitdefender for joining us. You can find the complete report on the Pacifier APT on Bitdefender's website. Cyber threats are evolving every second, and staying ahead is more than just a challenge. It's a necessity. That's why we're thrilled to partner with ThreatLocker, Thank you. and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today to see how a default-deny approach can keep your company safe and compliant.

The CyberWire Research Saturday is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner. Thanks for listening.