I have been writing about the ".well-known" directory a few times before. Recently, about attackers hiding webshells [1], and before that, about the purpose of the directory and why you should set up a "/.well-known/security.txt" file. But I noticed something else when I looked at today's logs on this web server. Sometimes you do not need a honeypot. Some attackers are noisy enough to be easily visible on a busy web server. This time, the attacker hit various URLs inside the ".well-known" directory. Here is a sample from the > 100 URLs hit:

It is typical for Apple to release a ".0.1" update soon after releasing a major new operating system. These updates typically fix various functional issues, but this time, they also fix a security vulnerability. The security vulnerability not only affects the "26" releases of iOS and macOS, but also older versions. Apple released fixes for iOS 18 and 26, as well as for macOS back to Sonoma (14). Apple also released updates for WatchOS and tvOS, but these updates do not address any security issues. For visionOS, updates were only released for visionOS 26.

In SANS FOR577[1], we talk about timelines on day 5, both filesystem and super-timelines. but sometimes, I want something quick and dirty and rather than fire up plaso, just to create a timeline of .bash_history data, it is nice to just be able to parse them and, if timestamps are enabled, see them in a human-readable form. I've had some students in class write scripts to do this and even had one promise to share it with me after class, but I never ended up getting it so I decided to write my own. This script takes the path to 1 or more .bash_history files and returns a PSV (pipe separated values) list (on stdout) in the form: <filename>|<datetime>|<command> where the <datetime> is in ISO-8601 format (the one true date time format, but only to 1 sec resolution since that his the best that the .bash_history file will give us). In a future version I will probably offer an option to change from PSV to CSV. 

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

Looking at our web honeypot data, I came across an odd new request header I hadn't seen before: "X-Forwarded-App". My first guess was that this is yet another issue with a proxy-server bucket brigade spilling secrets when a particular "App" is connecting to it. So I dove in a bit deeper, and found requests like this:

When you’re debugging a malware sample, you probably run it into a debugger and define some breakpoints. The idea is to take over the program control before it will perform “interesting” actions. Usually, we set breakpoints on memory management API call (like VirtualAlloc()) or process activities (like CreateProcess(), CreateRemoteThread(), …).

The recent (and still ongoing) phishing of NPM developer accounts showed yet again that even technically sophisticated and aware users are falling for phishing lures. Anybody will fall for phishing if a well-targeted e-mail is used.

Since the last update [5], over the past few months I added several enhancements to DShield SIEM and webhoneypot sensor collection that included an update to the interface to help with DShield sensor analysis. I updated the main dashboard to have all the main analytic tools listed on the left for quick access to all the sub-dashboards.

On the Stormcast, Johannes talked about BASE64 and DNS used by a backdoor.

YARA is an excellent tool that most of you probably already know and use daily. If you don't, search on isc.sans.edu, we have a bunch of diaries about it[1]. YARA is very powerful because you can search for arrays of bytes that represent executable code. In this case, you provide the hexadecimal representation of the binary machine code.