On October 5th, Atlassian published patches for multiple products to fix an "Arbitrary File Access" vulnerability [CVE-2026-21589]. An attacker can read arbitrary files in the web application's directory, potentially exposing sensitive information such as configuration files.

This directory traversal vulnerability is a little bit different from the textbook case. Atlassian products replace slashes with the pattern "::". To avoid this issue, but may, in some cases, undo this escape to access files.  Watchtowr has a great write-up with all the details and proof-of-concept URLs demonstrating the vulnerability [Watchtowr].

Starting yesterday, we saw some exploit attempts hitting our honeypot, using the exploit URLs mentioned in the Watchtowr blog. 

/download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml
/s/1.0/_/download/resources/com.atlassian.bitbucket.server.bitbucket-webpack-INTERNAL:avatar/avatar/..::..::..::..::..::WEB-INF::urlrewrite.xml
/s/1/_/download/resources/com.atlassian.confluence.plugins.dashboard-actions/images/..::..::..::..::..::..::..::..::WEB-INF::web.xml

One condition for successful exploitation is that the file the user attempts to access exists. The exploit uses "WEB-INF/web.xml" as it is a required file for Tomcat applications, and can be used similarly to "/etc/passwd". The "/etc/passwd" file will not work in this case. Access is restricted to the web application's directory. The "::" pattern used in the exploit will be translated to "/" on the server, leading to the directory traversal.

Based on the timing and the targets hit, I believe these scans are all triggered by the same threat actor. Oddly enough, all the source IPs are associated with Digital Ocean. The source IPs I see from our honeypots:

134.199.229.190
134.199.230.82
137.184.112.247
137.184.33.84
143.198.103.58
143.198.132.93
146.190.169.1
146.190.172.250
159.223.199.218
164.92.68.152
209.38.147.216
24.199.101.184
64.23.172.129 

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

It seems that a trend started… I continue my journey discovering more RMM ("Remote Management & Monitoring") tools abused by threat actors! A few days ago, I wrote a diary[1] about ScreenConnect used in the wild. Today, I found another one.

Same scenario, it started with a phishing email that delivers a fake PDF invoice to the victim:

When the PDF is opened, it just redirect to a malicious VBS file. Indeed, the PDF contains an “OpenAction” and “URI” keywords, that sounds weird! 

remnux@remnux:~/files/samples$ pdf-parser.py Transaction\ Receipt\ .pdf -o 3
obj 3 0
Type: /Page
Referencing: 1 0 R, 2 0 R, 4 0 R

  <<
    /Type /Page
    /Parent 1 0 R
    /Resources 2 0 R
    /MediaBox [0 0 595.2799999999999727 841.8899999999999864]
    /Annots
      <<
        /Type /Annot
        /Subtype /Link
        /Rect [0. 841.8899999999999864 595.2799999999999727 71.3010032362460606]
        /Border [0 0 0]
        /A
          <<
            /S /URI
            /URI (hxxps://up-theta-rose.vercel[.]app/adobe_new_update.vbs)
          >>
      >>
    ] /Contents 4 0 R
  >>

The URL will be visited thanks to the OpenAction. This is a common trick to avoid writing URLs in email bodies that can be easily detected.

The VBS file is pretty simple and even not obfuscated. It will display another PDF as a decoy: a non-blurred version of the initial attachment.

In parallel, a MSI archive will be downloaded and installed:

hxxps://up-theta-rose.vercel[.]app/action1.msi

The MSI file contains 4 files that are not reported as malicious by VT:

$ sha256sum *
eaff35d250c9b04f51c971e70082740dbfeee5dd846829d541f588ad43378727  a1_7z_dll_file
996b01e15f85e165899630721a141b178a9c372b6e878012180ec9e9d4e7bd06  a1_sas_dll_file
1b19115d5ebdc216e0ab3adf2c643648cfc70a385f4caf0217c679f9f3b20342  action1_remote_exe
941695d20d82dd5d62f74b0111feb23720637202f6c797df2a02e2cb6cb6e8e3  main_service_exe

These files belongs to the RMM tool developed by Action1[2] and are signed with an "Action1 Corporation" certificate that expired in May 2026. 

The tool installs itself as a service for persistence ("A1Agent" - "Action1 Agent"), executing C:\Windows\Action1\action1_agent.exe.

The registy key "HKLM\Software\Action1\Agent" contains the values: CustomerId, Certificate, PrivateKey, MSI & INSTALLDIR.

The CustomerID is: 49b18106-681d-456a-b098-092e2818c09a and is connecting to the Action1 infrastructure via server[.]na-2.action1[.]com.

We are facing here the same behaviour: the threat actor abuse the cloud infrastructure of the company developing the RMM tool, probably using a free/test account.

[Update 15:11 CET]

A second sample reached my mailbox, this take mimicking a DHL document:

The URL in the PDF is similar, it contains a URL (hxxps://update-two-tau[.]vercel[.]app/adobe-ne) pointing to a ZIP archive with an HTA script. It delivers the same MSI file.

[1] https://isc.sans.edu/diary/ScreenConnect+Client+Abused+by+Attackers/33388
[2] https://www.action1.com/remote-access/

Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key

For an experiment, I created a script [1] that parses and send the TTY logs collected from actors or bots activity that run various commands after they successfully login the DShield sensor. Those TTY logs are sent daily at the end of each day to the DShield SIEM [2] to be correlated with all the data. 

The following ES|QL query provides a summary of all contab commands matching a TTYLog hash performed by different actors while logged in the sensor over a 90 day period. 

TTYLogs Correlation

FROM cowrie* 
| WHERE transaction.id == "f904275333aeac48d7df6cf53fe5fb9212c7d132a7d37253d2ab9321ba2690d8"
| WHERE event.hash IS NOT NULL
| KEEP transaction.id, event.hash
| STATS Total=COUNT(event.hash) BY event.hash, transaction.id
| SORT Total DESC

This transaction ID captured 5 similar crontab commands that are translated from its hash equivalent into this list executed by more than 3130 different actors (IPs):

TTYLogs Sources

transaction.id: f904275333aeac48d7df6cf53fe5fb9212c7d132a7d37253d2ab9321ba2690d8 over a 90 day period

Other example of Event Hash decoded and sent to DShield SIEM for analysis

Top 10 Indicators

      IP                      ASN
102.88.137.80        29465
42.96.20.16            131423
182.253.221.210    38482
46.188.119.26         8334
159.223.97.218       14061
185.158.22.150       210022
193.233.48.169       207713
209.99.190.200       402253
45.64.74.51              55933
202.152.148.27        23951

[1] https://github.com/bruneaug/DShield-Sensor/blob/main/sensor_scripts/daily_tty.sh
[2] https://github.com/bruneaug/DShield-SIEM
[3] https://www.elastic.co/docs/reference/query-languages/esql

-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Sometimes I have to smile, or my interest is triggered, when I review new User Agent Strings in the honeypot logs.

Like when I see an "authorized" scan:

Or when I'm owned for the umpteenth time:

I regularly see URLs or email addresses for when you want to know more, or get in touch, with the persons behind a scanner:

(around the end of this list, you'll see the Belarus email address we wrote about recently)

Many variants of masscan:

Even a KGB variant.

As you can guess, "scan" is a popular word to include in your UAS:

And some wordplays are thrown in:

And they do not shy away from discrediting:

Sometime complete lists of User Agent Strings are used: the scanner will select a new UAS for each request. They don't always sanitize these list, as you can see with these weird "User Agent Strings":

These lines actually appear in this repository of User Agent Strings, to separate them in groups:

And because of a lack of quality control, these separator lines also get used as UAS in a request.

Of course, there are also attempts to exploit the parsing of a User Agent String. Shellshock may be more than 10 years old, I still see it in User Agent Strings:

And sometimes I think: "Huh, are they scanning for this too?". Like the last one:

Scanning for servers that stream GPS correction data via the NTRIP protocol (a NTRIP header was also included in this request).

Didier Stevens
Senior handler
blog.DidierStevens.com

YARA-X's 1.21.0 release brings 5 improvements and 4 bugfixes.

One improvement is allowing stdin for CLI option --scan-list.

This allows one to generate a list of folders to scan, and pass it via a pipe. Like this example (Windows) to scan all folders with "sample" in their name:

dir /s /b /a:d c:\*samples* | yr.exe scan --scan-list - rules.yara

Didier Stevens
Senior handler
blog.DidierStevens.com

Threat Actors do not always use top-notch techniques or very complex malware to perform their attacks. Sometimes, they just abuse of existing applications...

I received a very simple phishing email:

From: contact@mejuri[.]com
To: <redacted>
Subject: EFT Wire Transfer

Paid Invoice Receipt

Dear Customer,
Payment of $5745.65 was Received.
Please click here to view your Order Information in PDF
If this charge wasn't authorized by you, contact our customer service to cancel and
receive an immediate refund.

Digitally Yours,
Customer Support: +1(332)638474823

“Click here” is a link pointing to:

hxxps://thelittlecupandsaucer[.]com[.]au/ScreenConnect.ClientSetup.exe

This email passed all the basic security controls. The link points to a real PE file. Today this attack vector will be blocked by browsers because downloaded an executable is suspicious!

The PE file was unknown on VT so I did a quick analysis of it. It’s a legit application: a ScreenConnect[1] client preconfigured to call-back a test account operated by the Attacker. Here is the configuration extracted from the PE file:

The PE is signed by ConnectWise, LLC (DigiCert G4 Code Signing CA1). The Authenticode digest matches the signed digest exactly. There's no overlay and nothing appended to or injected into the certificate table, so the signed-but-tampered config trick isn't used here.

Such tools are a gold mine for attackers because they are easy to deploy and trusted by most used! The list of “RMM” (Remote Monitoring and Management) tools is huge. Here is a brief list of the well-known ones;

• ScreenConnect
• AnyDesk
• TeamViewer
• LogMeIn
• Bomgar (BeyondTrust Remote Support)
• Zoho Assist
• Remote utilities like rutserv.exe
• NetSupport Manager
• SimpleHelp

If you want a better overview, check LOLRMM project [2] that maintains a list similar to the LOLBAS project!

[1] https://www.screenconnect.com
[2] https://lolrmm.io

Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key