Tag Archives: Security

How quickly do we patch? A quick look from the global viewpoint, (Mon, Jul 21st)

This post was originally published on this site

Since the ongoing “ToolShell” exploitation campaign, in which threat actors attack on-premise Sharpoint servers using a chain of two recently published vulnerabilities[1,2,3], is still on top of the cyber security news[4,5,6,7], I thought it might be a good time to look at the question of how quickly do we – as a global society – actually patch actively-exploited vulnerabilities when it comes to our internet-facing systems.

While this is admittedly a very complex topic, and in order to arrive at any detailed conclusions, an in-depth, long-term study would be needed, I believe that even a quick look at available data may show us some general (and hopefully interesting) trends.

Since I – on my own – lack the ability to periodically scan the entire internet and identify how many systems are affected and/or patched when it comes to specific vulnerability, I decided to use data gathered from Shodan using my TriOp tool[8] over the past 30 months. Specifically, I looked at the number of systems that Shodan detected as “vulnerable” to any vulnerability listed in the CISA KEV catalog[9] each day during that timeframe.

It should be mentioned at this point that Shodan is not capable of detecting all of the KEV vulnerabilities (of the approximately 1380 vulnerabilities currently listed in the KEV, it seems to be able to identify only between 200 and 250) and that even for those vulnerabilities it detects, the mechanisms it uses to identify whether a specific system is vulnerable are passive in nature. Therefore, the resulting numbers are – by necessity – not exact, since there is a significant potential for false-positive (or false-negative) identification. Nevertheless, this data still provides a good starting point.

From all the data, I removed CVEs for which Shodan detected less than 50 vulnerable systems (or – to be more exact – 50 public IP addresses) and then generated time charts for all of the rest.

Based on a quick visual analysis, it appears that (if we gloss over the sharp sudden decreases/increases that Shodan is prone to – see e.g. [10] – and omit other Shodan-introduced artifacts, such as sharp increases in detections most likely associated with new detection analytics) for most vulnerabilities, the number of affected systems decreases over time in more or less linear fashion, with a tendency to slowly level out… As you may see below, in some cases, the rate of decrease is slower than in others, which may be due to slower patching or due to Shodan (at least partially) not being able to recognize backported patches.

Data for CVE-2019-0211 

 

Data for CVE-2022-0028

 

Data for CVE-2023-20109

Although for some vulnerabilities, there were occasions when a sharper short-term decrease was visible in the number of vulnerable systems, these were always explainable not by increased patching but by removal of systems that reached their “end of life” from production environments.

This effect can be clearly seen in chart for an Exchange vulnerability CVE-2021-31207 (and in charts for two other Exchange vulnerabilities – CVE-2021-34523 and CVE-2021-34473), where we may observe a significant decrease of vulnerable IP addresses detected by Shodan starting at the end of April 2023 and ending in the early May 2023. This decrease is almost certainly related to the fact that Microsoft ended support for Exchange 2013 (which was affected by the vulnerability/vulnerabilities)  on April 11, 2023[11].

Data for CVE-2021-31207

To sum up, although we need to take the Shodan numbers with a grain of salt, and although vulnerabilities in CISA KEV may not necessarily be the most important ones from everyone’s perspective, from what we’ve shown, it seems that even in July of 2025, the answer to the question of “How quickly do we patch?” is still “Not nearly quickly enough!”.

And while we’ve historically seen cases of vulnerabilities, where patching was relatively fast and the remaining “vulnerable population” was nearly insignificant (such as CVE-2019-19781 AKA “Shitrix”)[12], these – sadly – still seem to be the exception, rather than the rule…

 

[1] https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
[2] https://www.cisa.gov/news-events/alerts/2025/07/20/microsoft-releases-guidance-exploitation-sharepoint-vulnerability-cve-2025-53770
[3] https://research.eye.security/sharepoint-under-siege/
[4] https://www.bleepingcomputer.com/news/microsoft/microsoft-sharepoint-zero-day-exploited-in-rce-attacks-no-patch-available/
[5] https://thehackernews.com/2025/07/critical-microsoft-sharepoint-flaw.html
[6] https://www.securityweek.com/sharepoint-under-attack-microsoft-warns-of-zero-day-exploited-in-the-wild-no-patch-available/
[7] https://www.helpnetsecurity.com/2025/07/20/microsoft-sharepoint-servers-under-attack-via-zero-day-vulnerability-with-no-patch-cve-2025-53770/
[8] https://isc.sans.edu/diary/27034
[9] https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[10] https://isc.sans.edu/diary/SSL+20+turns+30+this+Sunday+Perhaps+the+time+has+come+to+let+it+die/31664
[11] https://learn.microsoft.com/en-us/troubleshoot/exchange/administration/exchange-2013-end-of-support
[12] https://isc.sans.edu/diary/26900

———–
Jan Kopriva
LinkedIn
Nettles Consulting

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

Critical Sharepoint 0-Day Vulnerablity Exploited CVE-2025-53770 (ToolShell), (Sun, Jul 20th)

This post was originally published on this site

Microsoft announced yesterday that a newly discovered critical remote code execution vulnerability in SharePoint is being exploited. There is no patch available. As a workaround, Microsoft suggests using Microsoft Defender to detect any attacks. To use Defender, you must first configure the AMSI integration to give Defender visibility into SharePoint. Recent versions of SharePoint have the AMSI integration enabled by default.

Microsoft also states: "If you cannot enable AMSI, we recommend you consider disconnecting your server from the internet until a security update is available."

Defender will just detect the post-exploit activity. Currently, webshells are observed as a payload being deployed, taking advantage of the vulnerability.

The best write-up and details I found so far come from the Eye Security research team. They initially used CVE-2025-49704 and CVE-2025-49706 to identify the vulnerability. Later, Microsoft confirmed that this is a new issue and started using CVE-2025-53700. This latest issue appears to be a variation of the older vulnerabilities patched in this month's Patch Tuesday.

The vulnerability exploits an authentication bypass issue triggered by setting the "Referer" header to "/_layouts/SignOut.aspx". This vulnerability is then exploited to trigger remote code execution via "/_layouts/15/ToolPane.aspx". 

In our honeypot data, we observed two instances of the "ToolPane.aspx" URL, first on July 16th (on individual hit, I am waiting to hear from the submitter to see if there are details available). Today, we received additional reports, but they originated from p55001.probes.atlas.ripe.net:9000 and are likely related to scanning for research purposes. These hits did not include the Referer header to trigger the vulnerabiliy.

The hit on July 16th originated from %%ip:172.174.82.132%%. This IP address appears to be owned by Microsoft.

Microsoft Advisory:
https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
Eye Security Blog:
https://research.eye.security/sharepoint-under-siege/

 


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.

Veeam Phishing via Wav File, (Fri, Jul 18th)

This post was originally published on this site

A interesting phishing attempt was reported by a contact. It started with a simple email that looked like a voice mail notification like many VoIP systems deliver when the call is missed. There was a WAV file attached to the mail[1].

Here is a transcript of the recording:

"Hi, this is xxxx from Veeam Software. I'm calling you today regarding … <not clear> … your backup license which has expired this month. Would you please give me a call to discuss about it?"

This was not targeted because the person who received the mail was not involved with Veeam (or any IT environment). Did you receive such emails recently or in the past?

[1] https://blog.rootshell.be/stuff/veeam-voicemsg.wav

Xavier Mertens (@xme)
Xamecosys
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

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

Hiding Payloads in Linux Extended File Attributes, (Thu, Jul 17th)

This post was originally published on this site

This week, it's SANSFIRE[1]! I'm attending the FOR577[2] training ("Linux Incident Response & Threat Hunting"). On day 2, we covered the different filesystems and how data is organized on disk. In the Linux ecosystem, most filesystems (ext3, ext4, xfs, …) support "extended file attributes", also called "xattr". It's a file system feature that enables users to add metadata to files. These data is not directly made available to the user and may contain anything related to the file (ex: the author's name, a brief description, …). You may roughly compare this feature to the Alternate Data Stream (ADS) available in the Windows NTFS filesystem.

Keylogger Data Stored in an ADS, (Tue, Jul 15th)

This post was originally published on this site

If many malware samples try to be "filess" (read: they try to reduce their filesystem footprint to the bare minimum), another technique remains interesting: Alternate Data Streams or "ADS"[1]. This NTFS feature allows files to contain multiple data streams, enabling hidden or additional metadata to be stored alongside the main file content without being visible in standard file listings. A common usage of ADS is the "Mark of the Web"[2] that helps to flag files as suspicious or not depending on their origin.

DShield Honeypot Log Volume Increase, (Mon, Jul 14th)

This post was originally published on this site

The volume of honeypot logs changes over time. Very rarely are honeypot logs quiet, meaning that there are no internet scans or malicious activity generating logs. Honeypots can see large increases in activity [1], but this has tended to be the exception, rather than the rule. Within the last few months, however, there has been a dramatic increase in honeypot log volumes and how often these high volumes are seen. This has not just been from my residential honeypot, which has historically seen higher log volumes, but from all of the honeypots that I run and archive logs from frequently. 

Experimental Suspicious Domain Feed, (Sun, Jul 13th)

This post was originally published on this site

We have had a "newly registered domain" feed for a few years. This feed pulls data from ICANN's centralized zone data service (https://czds.icann.org) and TLS certificate transparency logs.

The ICANN CZDS is a good start, but it only offers data from top-level domains collaborating with ICANN. Missing are in particular country-level domains. Country-level zone files can be hard to come by, so we use TLS certificate transparency logs as a "cheap" alternative. Pretty much all domain registrars will, by default, create a "parked" website, and with that, they will make a certificate. Even if they do not, any halfway self-respecting phishing site will use TLS and register a certificate with a public certificate authority at one point. The TLS certificate transparency logs also help capture older domains.

Each day, we capture around 250,000 new domains using this system. But of course, we want to know which domains are used for malicious purposes. However, as the sample below shows, there are a lot of "odd" domain names.

domainname
jgcinversiones.com
h20manager.net
1sbrfreebet.com
stability.now
mdskj.top
internationalone19.com
clistrict196.org
agenteinsider.com
720airpano.com
dhofp.tax
bos228btts.lol
japansocialmarketing.org
mummyandimedia.com
1dyzfd.buzz
oollm.shop
snapztrailk.store
perumice.com
nrnmy.sbs
commaexperts.com
softfragments.com

So I searched for some commonly used criteria to identify "bad" domain names, and found these:

  • A domain name is very short or very long
  • The entropy of the domain name (is it just random characters?)
  • Does it contain a lot of numbers or hyphens?
  • Is it an international domain name, and if so, is it valid? Does it mix different scripts (=languages)?
  • Does it contain keywords like "bank" or "login" that are often used with phishing sites, or brand names like "Apple" or "Google"?

We have now added a score to each domain name that can be used to rank them based on these criteria. You can find a daily report here, and the score was added to our "recentdomain" API feed. This is experimental, and the exact algorithm we use for the score will change over time.

We used to have an "old" supicous domain feed that was mostly based on correlating a few third party feeds, but over time these feeds went away or became commercial and we could no longer use them.

Feedback is very welcome.


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.

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

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: