Tag Archives: SANS

Analyzing Sharepoint Exploits (CVE-2025-53770, CVE-2025-53771), (Wed, Jul 23rd)

This post was originally published on this site

A few days after the exploit originally became widely known, there are now many different SharePoint exploit attempts in circulation. We do see some scans by researchers to identify vulnerable systems (or to scan for common artifacts of compromise), and a few variations of the "ToolPane.aspx" URL being hit. Even for our "random" honeypots, the number of hits has increased significantly without having to emulate SharePoint better.

WinRAR MoTW Propagation Privacy, (Tue, Jul 22nd)

This post was originally published on this site

Since WinRAR 7.10, not all Mark-of-The-Web data (stored in the Zone.Identifier Alternate Data Stream) is propagated when you extract a file from an archive.

Take my DidierStevensSuite.zip file that I downloaded with a browser in normal mode. It has the following Zone.Identifier ADS:

Not only does it have a ZoneId field that indicates the origin of the file (3 = Internet), but it also has ReferredUrl and HostUrl fields that tell use from where the file was downloaded.

If we now open this zip file with WinRAR (version 7.10 or later) and extract one or more files (I extract file AnalyzePESig-crt-x64.exe):

Many archive utilities like WinRAR will propagate the MoTW information: it means that they copy the Zone.Identifier ADS from the downloaded archive to the extracted files.

But if we take a look at the Zone.Identifier ADS from extracted file AnalyzePESig-crt-x64.exe, we see that the ReferredUrl and HostUrl fields have disappeared:

That's because since version 7.10, WinRAR has a privacy feature that redacts the Zone.Identifier information: only the ZoneId field is propagated, not the other fields.

This is a default setting that can be disabled (Zone value only):

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.

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.

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. 

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: