Monthly Archives: July 2025

Security

Setting up Your Own Certificate Authority for Development: Why and How., (Wed, Jul 9th)

Leave a comment
This post was originally published on this site

There are several reasons why one would set up an internal certificate authority. Some are configured to support strong authentication schemes, some for additional flexibility and convenience. I am going to cover the second part. In particular, it can be helpful for developers to have an internal certificate authority to issue certificates for development purposes. Websites used for development and internal testing are usually only used by a few individuals and are generally only accessible via internal networks or VPNs. Often, these sites do not even use TLS. But there are a few reasons why you should consider running TLS on all sites, including internal development sites:

Security

What's My (File)Name?, (Mon, Jul 7th)

Leave a comment
This post was originally published on this site

Modern malware implements a lot of anti-debugging and anti-analysis features. Today, when a malware is spread in the wild, there are chances that it will be automatically sent into a automatic analysis pipe, and a sandbox. To analyze a sample in a sandbox, it must be "copied" into the sandbox and executed. This can happen manually or automatically. When people start the analysis of a suspicious file, they usually call it "sample.exe", "malware.exe" or "suspicious.exe". It's not always a good idea because it's can be detected by the malware and make it aware that "I'm being analyzed".

Security

A few interesting and notable ssh/telnet usernames, (Sun, Jul 6th)

Leave a comment
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.