MAR-10334057-1.v1: Pulse Secure Connect

This report is provided "as is" for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information contained herein. The DHS does not endorse any commercial product or service referenced in this bulletin or otherwise.

This document is marked TLP:WHITE--Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol (TLP), see http://www.cisa.gov/tlp.

Description

CISA received four (4) files related to a Pulse Secure Perl Common Gateway Interface (CGI) exploit.

Three (3) of the files (DSUpgrade.pm, tnchcupdate.cgi and healthcheck.cgi) are webshells that have been modified. The primary purpose of these modifications is to provide a remote operator command and control (C2) access to a compromised device.

The last file (dsclslog) is a Linux command line utility designed to remove access or event log files. This analysis is derived from malicious files found on Pulse Connect Secure devices.

For a downloadable copy of IOCs, see: MAR-10334057-1.v1.WHITE.stix.

Submitted Files (4)

359b86d7f20430f0418b8401be34251bcddcc8aa48803597d8d78caaa547c875 (DSUpgrade.pm)

47a8e0a09f87450a7d6984dc7b7700c477b76c155dae7733126de9dbb78d3ef4 (healthcheck.cgi)

779d5410b6974cacacfdcddd68e7dac2409ea7957b9be4ae049466bd550de63c (tnchcupdate.cgi)

8c103a004cdbfb42c82851822e2d5263e33970faa82b83e4cc1fe9697c1e6ef9 (dsclslog)

359b86d7f20430f0418b8401be34251bcddcc8aa48803597d8d78caaa547c875

Tags

trojanwebshell

Details

Antivirus

YARA Rules

No matches found.

ssdeep Matches

Description

This file is a modified version of a Pulse Secure Perl Module. Analysis of this patched-in code indicates it will leverage the sed command to inject a malicious webshell into the Pulse Secure system file /pkg/do-install (Figure 1). The purpose of the injected webshell is to accept a parameter named "id" from within an incoming web application post. The webshell will then process the data provided within the "id" parameter as an operating system command by executing it locally utilizing the system() function.

Screenshots

779d5410b6974cacacfdcddd68e7dac2409ea7957b9be4ae049466bd550de63c

Tags

webshell

Details

Antivirus

No matches found.

YARA Rules

No matches found.

ssdeep Matches

Description

This file is a modified version of a Pulse Secure Perl CGI file (Figure 2). It is designed to perform an initial check to determine whether data was passed into the web application within a parameter named "id". If this parameter is provided, the code will extract its contents and execute them on the target system using the system() function. If no "id" parameter is passed to the application, the code will simply execute the main() function of the original Pulse Secure application.

Screenshots

47a8e0a09f87450a7d6984dc7b7700c477b76c155dae7733126de9dbb78d3ef4

Tags

webshell

Details

Antivirus

YARA Rules

No matches found.

ssdeep Matches

Description

This file is a Pulse Secure CGI script with malicious code patched to the end of the file (Figure 3 and 4).

If the system receives a POST request that match any one of the following three conditions it will trigger the malicious code. Otherwise, it defaults to the original Pulse Secure application.

Condition 1: The attacker submits a RC4 encrypted and base64 encoded shell command under the 'cert' parameter. The command is base64 decoded and RC4 decrypted before it is executed. The command's output is sent to the attacker.

Condition 2: The attacker provides input to two parameters: 'img' and 'name'. Then it calls the function (sub c), which only processes input to the 'img' parameter. The input is base64 decoded and RC4 decrypted to a file path. The associated file is read and returns to the attacker.

Condition 3: The attacker submits RC4 encrypted and base64 encoded shell commands under the 'name' parameter, leaving the parameter 'img' blank. The shell command is base64 decoded and RC4 decrypted before it is executed and the command output is RC4 encrypted and base64 encoded before sending to the attacker.

The following functions describe the encryption scheme employed by the malware (Figure 3).

sub r: This function generates random bytes to be used in (sub a) for encryption.

sub a: First it calls the (sub r) function to obtain a random six bytes ($k), which is prepended to the hard-coded passphrase ($ph) and forms the RC4 encryption key to encrypt the string ($st). The encrypted string is then base64 encoded.

sub b: First, it base64 decodes the input string. The decoded string ($s) is separated into the first six bytes ($k) and the rest without the first six bytes ($en). The first six bytes ($k) is prepended to the hard-coded passphrase ($ph) and forms the RC4 decryption key ($k.$ph) to decrypt the string ($en).

Screenshots

8c103a004cdbfb42c82851822e2d5263e33970faa82b83e4cc1fe9697c1e6ef9

Tags

utility

Details

Antivirus

No matches found.

YARA Rules

No matches found.

ssdeep Matches

No matches found.

Description

This ELF binary is a command-line utility that removes the .vc1 and .vc2 of the event log file or access log file. It requires the '-f' argument (Figure 5) followed by specifying which type of log (access/event) to be removed. When no argument is provided, it prints the usage information: "Usage:dsclslog -f [events|access] -r [Regex1,Regex2,Regex3,...]".

When executed with the '-f' option followed by access or event, the message "Select log file:/home/runtime/logs/log.[access/event].vc0" will be displayed on the console.

It copies the content of /home/runtime/logs/log.[access/event].vc0 into /home/runtime/logs/log.[access/event].vc1 and the content of /home/runtime/logs/log.[access/event].vc1 into /home/runtime/logs/log.[access/event].vc2. This results in three log files containing the same .vc0 contents.

Then it executes the following move 'mv' and remove 'rm' commands, resulting in removing log files ending with .vc1 and .vc2, leaving only the .vc0. The purpose of this operation could be anti-forensic by removing the access or event log files at the choice of the attacker.

--Begin commands removing log files--
mv /home/runtime/logs/log.[access/event].vc2 /home/runtime/logs/log.[access/event].vc0
rm /home/runtime/logs/log.[access/event].vc1
--End commands removing log files--

The message "Clearlog success!" is displayed after the operation.

Screenshots

CISA recommends that users and administrators consider using the following best practices to strengthen the security posture of their organization's systems. Any configuration changes should be reviewed by system owners and administrators prior to implementation to avoid unwanted impacts.

• Maintain up-to-date antivirus signatures and engines.
• Keep operating system patches up-to-date.
• Disable File and Printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
• Restrict users' ability (permissions) to install and run unwanted software applications. Do not add users to the local administrators group unless required.
• Enforce a strong password policy and implement regular password changes.
• Exercise caution when opening e-mail attachments even if the attachment is expected and the sender appears to be known.
• Enable a personal firewall on agency workstations, configured to deny unsolicited connection requests.
• Disable unnecessary services on agency workstations and servers.
• Scan for and remove suspicious e-mail attachments; ensure the scanned attachment is its "true file type" (i.e., the extension matches the file header).
• Monitor users' web browsing habits; restrict access to sites with unfavorable content.
• Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs, etc.).
• Scan all software downloaded from the Internet prior to executing.
• Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs).

Additional information on malware incident prevention and handling can be found in National Institute of Standards and Technology (NIST) Special Publication 800-83, "Guide to Malware Incident Prevention & Handling for Desktops and Laptops".

• 1-888-282-0870
• CISA Service Desk (UNCLASS)
• CISA SIPR (SIPRNET)
• CISA IC (JWICS)

CISA continuously strives to improve its products and services. You can help by answering a very short series of questions about this product at the following URL: https://us-cert.cisa.gov/forms/feedback/

What is a MIFR? A Malware Initial Findings Report (MIFR) is intended to provide organizations with malware analysis in a timely manner. In most instances this report will provide initial indicators for computer and network defense. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.

What is a MAR? A Malware Analysis Report (MAR) is intended to provide organizations with more detailed malware analysis acquired via manual reverse engineering. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.

Can I edit this document? This document is not to be edited in any way by recipients. All comments or questions related to this document should be directed to the CISA at 1-888-282-0870 or CISA Service Desk.

Can I submit malware to CISA? Malware samples can be submitted via three methods:

• Web: https://malware.us-cert.gov
• E-Mail: submit@malware.us-cert.gov
• FTP: ftp.malware.us-cert.gov (anonymous)

CISA encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found on CISA's homepage at www.cisa.gov.