It is about a week since the release of the four CUPS remote code execution vulnerabilities. After the vulnerabilities became known, I configured one of our honeypots that watches a larger set of IPs to specifically collect UDP packets to port 631. Here is a quick summary of the results.

We do see plenty of scanning to enumerate vulnerable systems, but at this point, no evidence of actual exploitations. But the honeypot is not responding to these requests, so we may be missing post-recon attempts to exploit the vulnerability

Top URLs

http://192.34.63.88:5674/printers/securitytest3/

The website is down now, but used to show a message that this is a scan to evaluate systems for research purposes. We do no t have a prior history from this IP address.

http://194.113.74.187:631/printers/amongus

Also no longer responding. The IP address is associated with security researcher Bill Demirkapi.

http://80.94.95.85:65000/printers/YmVuaWduYmUK "location_field" "info_field"

The string at the end of the URL decoded to "benignbe". The IP address was first seen last August scanning for various ports. The URL is no longer responding.

http://34.176.139.243/printers/YmVuaWducHJpbnRlcnMK "location_field" "info_field"

Note the similar base64 encoded string. This one decoded to "benignprinters". 

http://t828r8qoegavzdeaqtn5jd9umlsdg34s.oastify.com/printers/research_cups_if_we_find_you_are_vulnerable_we_will_let_you_know_via_responsible_disclosure

The URL hopefully identifies the purpose of the scan correctly :) . Oastify.com is used by the Burp collaboration server.

http://172.214.128.90:65000/printers/YmVuaWduYmUK "location_field" "info_field"

Another "benignbe" URL. Interestingly a Microsoft/GitHub IP address.

http://87.236.176.146:631/classes/2ef46bd9-ae8f4743 (and similar URLs with varying random end)

This IP is associated with internet-measurement.com.

So far, I only saw two "ipp" URLs:

ipp://146.70.100.229:80/printers/ "XXlocation" "XXinfo" "XXmake-and-model"

and 

ipp://199.247.0.94:631/printers/test

I will try to setup some automated responses soon to get a bit more detail.

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

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

Introduction

Setting up a DShield honeypot is just the beginning. The real challenge lies in configuring all the necessary post-installation settings, which can be tedious when deploying multiple honeypots. Drawing from personal experience and valuable feedback from past interns at the Internet Storm Center (ISC), I developed DShieldKickStarter to automate this often repetitive and time-consuming process.

What is DShieldKickStarter?

DShieldKickStarter is not a honeypot deployment tool. Instead, it’s a post-installation configuration script designed to streamline the setup of a honeypot environment after the DShield honeypot software has been installed. The script ensures that honeypots run efficiently with minimal manual effort by automating essential tasks such as setting up log backups, PCAP capture, and installing optional analysis tools.

Key Features of DShieldKickStarter

•    Automated Log Backups: The script organizes, compresses, and password-protects honeypot logs to prevent accidental execution of malicious files.
•    PCAP Capture Setup: Using tcpdump, it captures network traffic while excluding specific ports, ensuring relevant data is logged.
•    Optional Tool Installation: Cowrieprocessor and JSON-Log-Country are included as optional tools. Both were invaluable during my internship for streamlining data analysis.
•    Helpful for Multiple Honeypots: This script is handy when managing several honeypots. It saves time by automating repetitive setup tasks.

Step-by-Step Breakdown

The script automates several critical tasks:
1.    Creating Directories and Setting Permissions 
            Ensures the necessary directory structures for logs, backups, and PCAP data are in place, with proper permissions to secure sensitive files.
2.    Installing Required Packages 
             Installs essential tools such as tcpdump, git, and python3-pip, streamlining the log and packet capture setup.
3.    Configuring Log Rotation and Backups 
             Automatically rotates logs and stores them with password protection. PCAP files and honeypot logs are archived daily, and older backups are cleaned to save space.
4.    Automating PCAP Capture 
             Sets up tcpdump to capture network traffic, excluding predefined ports to ensure relevant data capture. The process is automated via cron jobs.
5.    Optional Tool Integration 
             The script optionally installs cowrieprocessor and JSON-Log-Country, two tools that were extremely helpful during my internship. These streamline log processing and help categorize attack data for further analysis.
6.    SCP Option for Off-Sensor Backup 
             If enabled, the script supports SCP transfers to a remote server, automating the secure transfer of backups for off-sensor storage.

Who Benefits from This?

•    ISC Handlers and Interns: This tool provides a streamlined process for post-installation setup, allowing for faster honeypot deployment and data collection.
•    Cybersecurity Professionals: This tool's time-saving features can benefit anyone interested in setting up a DShield honeypot and contributing to threat intelligence efforts.

Tool Showcase

1. CowrieProcessor

Description

CowrieProcessor is a Python tool designed to process and summarize Cowrie logs, allowing for more accessible and detailed analysis. Cowrie logs can contain overwhelming data as they track every interaction with the honeypot. CowrieProcessor condenses this data into a readable format, focusing on crucial elements like session details, IP addresses, commands entered by attackers, and malicious files downloaded during the session.

Usage and Benefits

The tool automates the parsing of Cowrie logs, providing a summary that includes key metrics such as session duration, attacker IPs, and the commands used during each attack. This is useful for quickly understanding attacker behavior without sifting through massive raw log files. With this, security teams can focus on actionable insights, such as blocking specific IPs or analyzing downloaded malware.

Screenshot Explanation

In the attached screenshot, CowrieProcessor provides a detailed view of a session from an attack on the honeypot. It shows session details, commands attempted by the attacker, and files downloaded, such as the malicious authorized_keys file. The easy-to-read output from CowrieProcessor highlights the attack flow, giving you insight into the malicious actor’s intentions.

CowrieProcessor output showing session details and malicious activities detected by the honeypot.

DShield SIEM (ELK)

Description

While DShield SIEM (ELK) is not included in the script, it is crucial in further analysis and data visualization for honeypots. ELK (Elastic Stack) enables the collection, processing, and real-time visualization of honeypot data. It provides a centralized platform to track attacker behavior, detect patterns, and generate insights through interactive dashboards.

Usage and Benefits

Using ELK, you can monitor key metrics such as the most frequent attacker IPs, session types, and the commands attackers use. ELK dashboards also provide the ability to create custom queries using Kibana Query Language (KQL), which allows you to filter logs by specific attributes like failed logins, session durations, or malicious file downloads.

ELK dashboard showing attack data, top IP addresses, session activity, and trends over time.

Screenshot Explanation

The attached screenshot shows a detailed ELK dashboard summarizing honeypot data. On the left side, the "Top 50 IP" table displays the most active attacking IPs, while the center pie charts break down the types of logs (honeypot, webhoneypot, etc.) and session activity. The bar chart on the right visualizes Cowrie activity over time, helping analysts track attack patterns. KQL can filter this data even further, focusing on specific attacks or malicious behaviors.

KQL (Kibana Query Language)

One of the standout features of ELK is the ability to leverage KQL for deep-dive investigations. For instance, if you want to search for all failed login attempts, you can use a KQL query like:
event.outcome: "login.failed"

This query will instantly filter your logs, allowing you to pinpoint where and when login attempts failed. Another useful query might be filtering by source IP to track all actions from a particular attacker:
source.ip: "45.148.10.242"

With KQL, you can quickly analyze data across large volumes of logs, making it easy to detect anomalies, potential threats, or patterns in attacker behavior.

[1] https://github.com/DShield-ISC/dshield
[2] https://github.com/iamjoshgilman/DShieldKickStarter
[3] https://github.com/jslagrew/cowrieprocessor
[4] https://github.com/justin-leibach/JSON-Log-Country
[5] https://github.com/bruneaug/DShield-SIEM
[6] https://www.elastic.co/guide/en/kibana/current/kuery-query.html
[7] https://www.sans.edu/cyber-security-programs/bachelors-degree/
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Over the last 9 months or so, I've been putting together some docker containers that I find useful in my day-to-day malware analysis and forensicating. I have been putting them up on hub.docker.com and decided, I might as well let others know they were there. In a couple of cases, I just found it easier to create a docker container than try to remember to switch in and out of a Python virtualenv. In a couple of other cases, it avoids issues I've had with conflicting version of installed packages. In every case, I'm tracking new releases so I can update my containers when new releases come out and I usually do so within a couple of days of the new release. The ones that I have up at the moment are the following:

clausing/flare-floss

clausing/capa

clausing/hayabusa

clausing/takajo

clausing/chainsaw

clausing/yara

clausing/uac

clausing/dfir-unfurl

The USAGE portion of each page should give enough info on how to run thems (and what directories to map into the container). Hopefully, some of the rest of you will find these useful.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

For a few years now, October has been "National Cyber Security Awareness Month". This year, it is a good opportunity for a refresher on some scams that tend to happen around disasters like Hurricane Helene. The bigger the disaster, the more attractive it is to scammers.

Fake Donation Sites

Hurricane Katrina was the first event that triggered many fake donation websites. Since then, the number of fake donation websites has decreased somewhat, partly due to law enforcement attention and hopefully due to people becoming more aware of these scams. These scams either pretend to be a new charity/group attempting to help or impersonate an existing reputable charity. People in affected areas need help. Please only donate to groups you are familiar with and who were active before the event.

AI Social Media Posts

I believe these posts are mostly created to gain social media followers, maybe with the intent to later reel them into some scam. They often post dramatic images created with AI tools or copied from legitimate accounts. Some may just be interested in some of the monetization schemes social media and video sites are participating. Do not amplify these accounts. Strictly speaking, they are not "fake news," but legitimate news sources who go out to take pictures and gather information need exposure more than these fake accounts. Often, the fake accounts will contribute to at least exaggeration of the impact of the event and reduce, in some cases, the credibility of legitimate recovery efforts

Malware

Attackers may use the event as a pretense to trick victims into opening attachments. In the past, we have seen e-mails and websites that spread malware claiming to include videos or images of the event. These attachments turn out to be executables installing malware.

Fake Assistance Scams

In the aftermath of a disaster, organizations often provide financial aid through loans. Scammers will apply for these loans using stolen identities traded online. If it may take several months for the victim to become aware of this, they often face a request to repay the loan. Sadly, there is not much, if anything, to protect yourself from these scams. The intend of the assistance is to be quick and unburocratic and to "sort things out later". You may have to prove that someone else used your information to apply for the loan.

"Grandparent Scam"

In this scam, a caller will pretend to be a relative or close friend, asking for money. These scams have improved because they can often identify individuals in the disaster area and use them as a pretense to extort money. The caller may claim to be the individual (often they use SMS or other text messaging services), or they may claim to represent a police department or a hospital. Do not respond to any demands for money. Notify your local police department. If you are concerned, try to reach out to the agency calling you using a published number (note that Google listings can be fake). Due to the conditions in affected areas, the local authorities may be unable to respond. Your local law enforcement agency may be able to assist. They often have a published "non-emergency" number you can use instead of 911. Individuals in the affected area may not be reachable due to spotty power and cell service availability.

Final Word

Please let us know if we missed anything. A final word on some disaster preparedness items with an "IT flavor":

1. Have a plan to get out, and if you can get out: get out. You should not stay in the affected area unless you are part of the recovery effort.
2. Cellular networks fail. Cellular networks tend to work pretty well during smaller disasters, but they need power, towers, and other infrastructure, which will fail in large-scale disasters. Satellite connectivity quickly becomes your only viable option (if you have power). If you have a phone with satellite emergency calling (for example, a recent iPhone), they offer a "demo mode" to familiarize you with the feature.
3. If you are lucky to already have a Starlink setup, bring the antenna inside before the storm and disconnect the equipment from power to avoid spikes destroying it.
4. Disconnect as many electric devices from outlets as possible during a power outage (or before power outages are expected). Power outages often come with power spikes and other irregular power events that can destroy sensitive electronics. Do not plug them back in until power is restored and stable.
5. Even a downed phone or cable TV line can be energized. You may not see the high voltage line that is also down and touches the cable TV line. I took the picture on the right this weekend in my neighborhood of a high-voltage line touching the cable TV and phone line.

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