The Hidden Threats of Potentially Unwanted Programs (PUPs)

Potentially Unwanted Programs (PUPs) – also known as Potentially Unwanted Applications (PUAs) – often come installed with freeware. Commonly referred to as junkware, bundleware, or adware, PUPs are software programs that employees in your organization may download unintentionally – programs that they do not plan to use. 

Whenever free software is downloaded to a computer in your organization, that computer may be inadvertently exposed to PUPs. Moreover, in some cases, PUPs actually are downloaded independently (rather than as freeware bundled with a second application). 

Because PUPs generally are not malicious by design, they are not classified as malware. As a result, the threat of PUPs is often underestimated; they frequently are not identified by security vendors and software. 

Disclaimer: In this post, we are going to explore what makes PUPs so dangerous. To do so, we’ll be using a somewhat unconventional approach: We’ll be illustrating exactly how quickly and easily anyone can create a malicious PUP, to illustrate the degree of the threat. We will also touch upon some of the mitigation measures that you can take to reduce the risk posed by PUPs – including the concept of whitelisting.

The Dangers of PUPs

It is easy to create a PUP and distribute it via free channels – and this makes it attractive to individuals involved in malicious activities. In fact, PUPs are a particularly fast, and practically free, means of distribution. 

There are dozens of PUPs in the wild; some are useful, providing free alternatives to paid software packages – while some are scams that are not what they purport to be.

PUPs perform a wide variety of helpful functions, acting as converters, utilities, driver management tools, cleaners, toolbars, and as helper software (browser assistants). 

There are two main security issues with PUPs:

  • PUPs can be updated – usually automatically. This means that they can be abused in supply chain attacks since in most cases their infrastructure and hosting servers are weak and unmanaged. 
  • PUPs may hide behind PUP, Adware, or Bundled signature detections – yet, in some cases, they can cause real damage.

A Case Study: CCleaner

CCleaner is a known utility program designed to delete unwanted files from a computer. It was designed to eliminate temporary files that eat up disk space and invalid Windows registry keys. During the cleanup, malicious files buried in the system are also deleted.

In July 2017, CCleaner was sold to antivirus vendor AVAST, and in September 2017, CCleaner became infected. Hackers compromised CCleaner’s build environment to insert malware in a type of supply chain attack. 

The malware was a stealer that collected information and sent it to attackers, while also providing a backdoor for attackers. More than 2 million users were infected. 

Here’s an example that shows that the infection involved adding only a few lines of code to CCleaner:

CCleaner payload

Malicious version of CCleaner

However, CCleaner is not a classic example of a PUP. Since AVAST took ownership of it and took the necessary steps to protect users from infection, it is a popular tool. Today, official versions of CCleaner are categorized as PUPs only by highly unreliable vendors. However, there are still bundled versions that are classified as PUPs or generic malware (even with what seems to be a valid signature):


VirusTotal showing Ccleaner identified as a PUP


Security Operations Teams: Beware! 

Check how many PUPs are installed on your computer. Now, multiply that by the number of workstations across your organization. 

It is likely you will want to delete all these PUPs – after reviewing the following proof of concept (POC) that illustrates how easy it is to use PUPs for malicious purposes.

The following POC is intended to encourage you to stop using questionable applications made by unknown vendors. If you are a CISO, please ensure that only official software is allowed by your organization’s security policies.

Looking at how short this process is, it’s easy to understand why PUPs are underestimated: In just 15 minutes, almost anybody with elementary technical prowess can build one.

Step 1: Start the POC

The “recipe” to create a new PUP is incredibly simple:

  1. Identify a commonly experienced problem or need; in this example, it’ll be converting PDFs into word documents.
  2. Develop an application that fills the gap or meets the need.
  3. Add malicious modules to your app.
  4. Create (or copy) a good-looking web page or use a known software distribution site.

Step 2: Develop the Code

The following POC uses Python – one of the easiest languages. Python’s ability to use available modules and libraries shortens our code to a minimum.

Select the modules necessary for the PUP:

  • Tkinter, for the user interface 
  • Pdf2docx module, for the conversion function
  • A few other helpers

code 1

Modules import

To convert a file from PDF to Word, we need just 2 lines of code:

code 2

Pdf2docs module manual

We’ll add to this: 

  • Input and output file
  • The canvas 
  • A call for a function allowing you to steal the document
code 3

Creating the “convert PDF to Word” functionality of the PUP

We can test the convert function and check it works:

simple pdf 2simple pdf 1 

Testing the conversion abilities of the PUP

The functionality works fine! It converts PDF to Word very well. At this point, the utility is done.

Step 3: Using the PUP for Malicious Activity

It is worryingly easy for a threat actor to add the most common hacker activities with just a few lines of code. The takeMeHome function is the simplest – and uses the socket module to send the file in chunks of 1024 bytes. 

Once the takeMeHome function is set up, a steganography module can be imported to hide data in pictures – using a default wallpaper picture that is present on any PC. In this example, we used the stegano module since we are keeping the code as short and simple as possible. (You could also use pyhide or SteganograPy – the most recent one, which has some additional functions.) Whatever you choose, make sure to do the decryption with the same module in your server-side code:

code 4

Adding the code for steganography encryption and sending the data

On the other side of the socket, we can use a simple Personally Identifiable Information (PII) scanner such as PII Catcher, and a regex-based sensitive info and passwords scanner, for example, Detect-Secrets. (This is currently beyond the scope for this POC. However, it would not require more than an additional 10 minutes to set up on the server side.) 

We can also integrate a few add-ons:

  • “Select File” and “Convert File” buttons
  • A fake progress bar, to make it look realistic

Behind a fake loading bar, we can collect information about the machine and the network connection – and send this information via the same takeMeHome.

code 5

code 6

Fake loading function and the buttons

At this point, we are about 7 minutes into this POC exercise, and we have 43 lines of code. (And I am not a fan of Pythoners’ one-liners!)

GetInfo can now create a temp file with all the data. It forwards the file to takeMeHome, then deletes the temp file:


GetInfo function

By testing the code, we can see how much information can easily be stolen:

code 8

Data collected by GetInfo function

We have a few minutes remaining before the 15-minute limit of this exercise. So, we can add a basic reverse-shell. This is initiated at the end of our main function: conPdf2Word().

Adding more code could create an evasive and persistent reverse shell, but as that is not the main idea of this POC – we will stop here.


Adding a basic reverse-shell

Step 4: Preparing the Campaign

To make the code look like a final product, PyInstaller is used to compile the code into an executable and combine the imported modules:


Compiling code with PyInstaller

If you have console output during your program execution, make sure to add the “—windowed” flag to hide the console.

We can add metadata using Resource Hacker. We want the metadata to be as reliable as possible. Here’s an example:

metadata resource hack

Adding metadata via ResourceHacker


Adding metadata via ResEdit

Finally, we can change the icon using Resource Hacker as well:

inner images-01

Changing the icon

Step 5: Running Detection Tests

Before we continue, we can run a few detection tests for the compiled file. Only two vendors detected the file:

2 detections VT PDF2WORD

We could try to make it harder – still using as little time as possible – by running the free UPX Packer:

UXP Packer

Running the free UPX packer

UPX Packer is infamous. It is a free tool often used by hackers to pack their executables. As a result, multiple vendors have added the ability to detect UPX packed executables (which are very easy to identify). Our file here is not signed, which makes it suspicious and is a trigger for some of the vendors. 

As you can see in this screen capture, the two vendors that previously detected our PUP are no longer detecting the file. Six other vendors detected the file, though these are primarily generic detections (False Positives) identifying the UPX packer and the unsigned file that makes it suspicious. 

6 detections PDF2WORD

Vendors detecting the PUP – generic detection

Step 6: Creating a Web Page

We are about 13 minutes into the POC. 

It takes 1 minute to copy and prepare a distribution page:

Fake dist page

Creating a Web page

There’s a minute left - but we are done! 

Step 7: Checking the Final Product 

The PUP that we developed does everything it was meant to do: It converts a PDF to Word; steals file and system information; and establishes a potential reverse shell:

inner images-03

Capabilities of the new PUP

The app looks a bit amateur, and it is missing exceptions and error handling, but the point was to build a simple POC in under 15 minutes – and we did it.

Disclaimer: This short POC was built within a specified, 15-minute time limitation. The goal of this POC is to underscore how dangerous it is to use questionable applications made by unknown vendors. 


Measures to Reduce the Risk of PUPs

We’ve demonstrated how easy it is to utilize PUPs for malicious purposes – with the goal of encouraging you to think twice before downloading PUP software. 

So, how do you avoid the risk posed by PUPs, at the organizational level? Whitelisting.

Whitelisting - One of the safest ways of ensuring that there are no PUPs or other unallowed applications in an organization -  allows only what is tested and known, and blocks any other application. 


Whitelisting vs. Blacklisting

What’s the difference between whitelisting and blacklisting?

Whitelisting means allowing only specific executables or applications that are known to be “good” – and blocking everything else. Only a few innovative security products – and even fewer organizations – successfully implement this approach.

Blacklisting means blocking the executables or applications that are known to be malicious. Most signature-based security software uses a blacklisting approach.

The key concept that differentiates between these two approaches is the word “known.” Each month, the cyber security community discovers many new vulnerabilities, malware techniques, and more. Blacklisting keeps employees away from the known threats; but whitelisting keeps employees away from unknown threats, as well.

Application Whitelisting Takes Your Organization’s Security to the Next Level 

Whitelisting is not easy to implement – especially in big and mature organizations – since employees are accustomed to downloading whatever they need to accomplish their assigned tasks. 

One step an organization can take – in order to monitor what’s installed on the endpoints – is the removal of local admin permissions, allowing only the IT team to install the software. 

In addition, a Security Operations Center (SOC) might consider taking steps to identify employees who download too many PUPs as a potential danger to the organization. 

Endpoint detection solutions like Managed Endpoint Detection & Response (MEDR) that are based on user behavior can provide the data necessary for identifying anomalous behavior. 

Beyond MEDR, a SOC also can develop rules in the Security Incident & Event Management (SIEM) platform that identify problematic user behavior – and determine malicious activities done by PUPs that look legitimate. 

Security awareness training is welcomed as well - ensuring that employees are sensitive to the problem and avoid using questionable applications with bad reputations.

Because implementing whitelisting is such a complex process, it’s best to work with a highly qualified and experienced SOC that can help you. An advanced SOC can integrate security software that uses artificial intelligence (AI), machine learning (ML), and behavior whitelisting. In other words, it can develop a setup in which specified, permitted actions in a system are allowed, but all other actions are blocked. An advanced SOC is able to investigate malicious activities and find their root cause – which in some cases, may be a PUP.

Want to learn more about how to implement application whitelisting and hunt for malicious PUPs? Contact CyberProof’s experts today!