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.

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.

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.

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.

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.

This post was originally published on this site

[This is a Guest Diary by Sihui Neo, an ISC intern as part of the SANS.edu BACS program]

As part of the SANS degree program curriculum, I had the opportunity to set up a honeypot to monitor log activities mimicking a vulnerable server. I used the AWS free tier EC2 instance to set up the honeypot sensor in Japan and deployed Cowrie, a SSH and Telnet honeypot designed to log brute force attacks and shell interaction performed by an attacker.

In addition to the sensor setup, to allow me to easily look at all the logs in a single platform, I purchased a separate virtual private server and installed ELK SIEM, following the setup instructions from ISC mentor, Guy Bruneau’s github page.[1] Then setup the sensor to send all logs to the SIEM server.

Since the setup of the honeypot, one of the interesting observations in logs was direct-tcp connection requests. More than 1000 different IPs within a month were seen to have made these requests and more than 75% were made to a single destination IP. In this post, I’ll cover how and why these connections are set up, and where the destination IP points to.

What did the logs look like?

Sample of direct-tcp connection request seen in honeypot logs

The sample log on the original event field seen above indicates that the request originated from 127.0.0.1 (the local loopback interface), but when looking at the source.ip in kibana, the actual source IPs were different external addresses. 

125.20.251.66 was the actual source IP

Using the source IP 125.20.251.66, I took a look at the traffic before the direct-tcp connection and the PCAP traffic.

Figure 1. Logs from 125.20.251.66 at the time of the direct-tcp connection request showing source port of 32069 in a red box

In Figure 1, I extracted the logs for traffic from source IP 125.20.251.66 as seen in kibana. The line direct-tcp connection request to 77.88.21.158:25 from 127.0.0.1:32069 is highlighted in the red box, yet the source address shows 125.20.251.66 while the source port matches 32069.

Additional evidence is in the PCAP. The entire stream below showed the connection using the source port of 42948, which was indeed the source port for the initial SSH connection as seen in the Figure 1 above, highlighted in a blue box, source IP seen in the last column.

Figure 2. PCAP and TCP stream for traffic from 125.20.251.66

Lastly, the SSH banner SSH-2.0-OpenSSH_7.4 was seen in Figure 1, highlighted in green as well as in the TCP Stream at the bottom of Figure 2. All these suggested that the traffic was being forwarded or proxied to help obscure the real source IP. 

So how does it work?

Reconnaissance and Initial access

As explained before, the attacker has to initiate a connection to the honeypot server to create a SSH tunnel and to do that, they require valid SSH login credentials. This is usually fulfilled by brute forcing. When looking at initial activities of IPs that had direct-tcp connection requests, they had a similar pattern of :

• Only attempting to connect to port 2222
• Throttled brute forcing attempts, meaning brute forcing attempts from the same IP were spaced out at least 2 hours if it failed.
• TTL of less than 50, means starting TTL is likely 64, which could be indicative of Linux/MAX OSX systems [3]
• SSH client hash fingerprint: acaa53e0a7d7ac7d1255103f37901306

After successfully obtaining valid SSH credentials, the SSH tunnel would usually be set up within the second.

Going somewhere?

As mentioned before, more than 1000 IPs were seen to have made these proxy connections in the honeypot and interestingly, the majority, more than 75%, were seen to be proxying to the destination IP of 77.88.21.158 at port 25.

77.88.21.157 port 25 seems to be the smtp server for yandex mail, based in Russia [4] which is a common blocked location for many countries.

Referencing the SSH tunnel diagram shown earlier, this likely means that the client set their email client to use ‘127.0.0.1:1080’ as the proxy, which instructed the email traffic to go through the established SSH tunnel to reach 77.88.21.158.

As the honeypot server does not really have SSH service on port 2222, the connection is closed quickly after the tunnel is set up and the PCAP logs do not capture outbound traffic to the destination IPs. 

What’s the worst that could happen?

Direct-tcp connections are usually a form of proxy connection that uses the honeypot server in this case, as an intermidiary to either mask origin IPs or to bypass traffic rules. The reason attackers use compromised servers instead of paid or free VPN is attribution and/or possibly consistency. Commercial VPN requires sign up and services like peer-to-peer networks do not usually allow users to choose the route or hops.

Establishing a SSH tunnel does not require root and can easily be set up as long as you have a valid user’s credentials to login to the SSH server (honeypot, in this case). In fact, brute forcing is one of the more common and easy tactics to gain access to vulnerable servers due to password leaks, reusing of passwords and default passwords.

Once your server is compromised and successfully used as a proxy, your server may be susceptible to:

• Malicious Traffic Attribution: Actors can route illegal activities (hacking, fraud, DDoS) through your server, making you appear responsible.
• Bandwidth Overuse: Proxy traffic consumes resources, which can lead to throttling by your host/ISP and extra costs especially in the cloud.
• IP Blacklisting: Your server’s IP may end up on firewall blacklists preventing you from your daily activities

[1] https://github.com/bruneaug/DShield-SIEM
[2] https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/
[3] https://www.imperva.com/learn/performance/time-to-live-ttl/
[4] https://search.censys.io/hosts/77.88.21.158
[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.