(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/8G5dQTp
via IFTTT

I noticed an increase in scans that appear to try to identify Elasticsearch instances. Elasticsearch is not a new target. Its ability to easily store and manage JSON data, combined with a simple HTTP API, makes it a convenient tool to store data that is directly accessible from the browser via JavaScript. Elasticsearch has, in particular, been popular for consolidating log data, and the "ELK" (Elasticsearch, Logstash, Kibana) platform has been a very successful standard for open source log management.

Call me old fashioned, but the idea of exposing my database directly to the user has always been a bit "frightening" to me. But the kids like to do dangerous things, and as a result we have plenty of exposed Elasticsearch instances. No surprise that attackers are looking for them.

The particular query I have been seeing these last couple days is "/_cluster/settings ". Running this against my own Elasticsearch instance:

$ curl -isku $ELASTIC_USERNAME:$ELASTIC_PASSWORD https://localhost:9200/_cluster/settings/
HTTP/1.1 200 OK
X-elastic-product: Elasticsearch
content-type: application/json
content-length: 32

{"persistent":{},"transient":{}}

does not really retrieve any concerning details, but it easily proves that we have a running Elasticsearch instance. 

Without authentication, a 401 error is returned, but again, there are no details about what version I am running. It is, however, possible that the formatting or the details of the error message can be used for fingerprinting.

 curl -isk https://localhost:9200/_cluster/settings/
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="security", charset="UTF-8"
WWW-Authenticate: Bearer realm="security"
WWW-Authenticate: ApiKey
content-type: application/json
content-length: 497

{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/_cluster/settings/]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}}],"type":"security_exception","reason":"missing authentication credentials for REST request [/_cluster/settings/]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}},"status":401}

My best guess is that this actor is just looking for possible instances of Elasticsearch to come back later for details. Elasticsearch is always somewhat scanned for, but the request for /_cluster/settings/ is new. The graph below compares all requests for Elasticsearch with requests for /_clustser/settings

This weekend, a blog post by cyberNK regarding an "Elastic EDR Zero-Day" made headlines [1]. I do not think these requests are related, and Elastic disputed the blog post [2].

[1] https://ift.tt/Hur5apS
[2] https://discuss.elastic.co/t/elastic-response-to-blog-edr-0-day-vulnerability/381093

—
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.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/m0lChR9
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/Im01Fuo
via IFTTT

I recently woke up (as one does each day, hopefully) and saw a few Microsoft MFA prompts had pinged me overnight.  Since I had just awakened, I just deleted them, then two minutes later clued in – this means that one of my passwords was compromised, and I had no idea which site the compromised creds were for.

I opened the MS Authenticator app on my phone, and saw no option for "view history" – this seems like a huge miss to me.

I finally found it in the MS portal at account.microsoft.com / my signins, which translates to: https://mysignins.microsoft.com/.  It's not so helpful that this information has moves ovr time, most of the online documentation tells you to navigate to your privacy settings to get to this page (which is not correct info for today's site).

Once you are there, this page nicely lists all the logins, successful or otherwise, as well as what site or resource they were for as well as the geography.  So if you are being attacked from abroad you can see that immediately in this page.  What it doesn't do is list the login geography and phone geography separately – that would be helpful, as if they don't match that's almost positively an attack, it takes the "I was on vacation" thing off the table (unless your organization uses proxies pre-vpn that is).

So perfect!  What does this mitigate against?  For me today, it tells me which site I need to change my password for.  Also it tells me that I need to contact that customer and tell them that they've been breeched somehow – all of my passwords are unique per-site and customer, so if one is compromised it's not because I used it on some less secure site – I'm not ordering take-out with any of my customer passwords for instance.

This doesn't mean that this customer has had a full compromise, that the attacker recovered it from AD (good luck with that against my longer, random string passwords) – more likely one of their web resources stores passwords in clear text or stores passwords using some reversible encryption.  This also means that organization is rocking it like it's 2005 – a web resource that's most likely using their on-premise AD as it's back-end authentication without MFA – then storing or caching the credentials, you know, for "performance reasons". (those same "performance reasons" that we fought against for years when implementing SSL/TLS).

What is the real attack vector here?  There are a couple:

• Ask Uber about MFA-bombing.  If you target someone junior enough – or senior enough, and send them 2-30-40 MFA requests, chances are that eventually they'll press "OK" to make the flood stop.  Or if the attacker can gain additional info on the target person (like say from LinkedIn), they can contact them via email or SMS, masquerade as an IT support person and instruct them to press "OK".  An MFA attack of this type against an Uber driver in 2022 ended up in a successful (but very brief) compromise. 
• Of course, if the compromise got around MFA protections (using either MFA bombing or some direct attack that bypasses authentication), the attacker is still free to pillage that site.  If they can pivot from that site, it's very likely that they'll find themselves on the inside network, where you can likely collect admin level creds from all sorts of places and own the whole shop.
• Even if the attacker can't find a decent pivot, now they've got working credentials, which they can leverage against anything else that you have that's internet facing – both those using MFA or not.  If they are persistent (that's the "P" in APT), eventually they'll find one that they can MFA Bomb, RCE or otherwise compromise, then pivot inbound from, which of course leads them to great destruction and victory, with tears from the target company to speed them on their way!

Many of you are likely admins for organizations though, so the single-person view isn't so useful.  As an administrator, can you see this same history information for your supported users?  Sort of, just without the actual maps (which aren't so useful anyway).  In https:portal.azure.com, navigate to identiy Protection / Dashboard / risk Detections.  Choose "View Attacks", then from there you can pick an individual user and list all of their logins. 

While I couldn't find an easy way to navigate to list all users (please use our comment field if you have that?), if you look in the URL, the report for a single user has a URL formatted as:
https://portal.azure.com/#view/Microsoft_AAD_IAM/SignInLogsList.ReactView/userObjectId/<User-GUID-goes -in-HEX-here>/timeRangeType/last1month

If you remove the "UserObjedId/<GUID> sections of the URL, this now lists all users in the organization.  From there you can filter the display as needed or simply export it an dice it up with Excel or whatever.

If you've got a way to get to this info directly, or better yet if you have a link to the API (which would allow you to pull this into your SIEM) or Powershell script that can collect this, by all means share in our comment form!

===============
Rob VandenBrink
rob@coherentsecurity.com

(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/NzLq2CG
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/CjYZlqw
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/OvNjPts
via IFTTT

As the world gradually adopts and transitions to using 5G for mobile, operational technology (OT), automation and Internet-of-Things (IoT) devices, a secure 5G network infrastructure remains critical. Recently, the Automated Systems SEcuriTy (ASSET) Research Group have released a new framework named SNI5GECT [pronounced as Sni-f-Gect (sniff + 5G + inject)] that enables users of the framework to i) sniff messages from pre-authentication 5G communication in real-time and ii) inject targeted attack payloads in downlink communications towards User Equipments (UE). I had previously written about how 5G connections are established over here, hence I will be diving directly into the SNI5GECT framework. In this diary, I will briefly provide an overview of the SNI5GECT framework and discuss a new multi-stage downgrade attack leveraging the SNI5GECT framework.

As mentioned earlier, SNI5GECT can sniff uplink (UL) and downlink (DL) 5G New Radio (NR) traffic over the air and inject downlink messages at the correct timing (i.e. after a specific protocol state) so the UE would accept the message in real-time. Such features allow SNI5GECT to fingerprint, perform denial-of-service, or downgrade attacks on targets requiring message injection under different communication states. Compared to prior state-of-the-art works, the SNI5GECT framework does not require rogue gNodeB (gNB) stations when executing over-the-air sniffing and stateful injections. The absence of a rogue gNB is significant as it reduces setup complexities while increasing stealth (e.g. avoiding rogue hardware detection mechanisms) since broadcast messages [Master Information Block (MIB) and System Information Block (SIB)] are not transmitted. With reference to Figure 1, the overview of SNI5GECT is illustrated.

Figure 1: Overview of Capabilities in SNI5GECT (figure reproduced with permission from ASSET Research Group) [1]

SNI5GECT consists of the following components (also illustrated in Figure 2):

• Syncher: Synchronizes time and frequency with the target base station.
• Broadcast Worker: Decodes broadcast information such as SIB1 and detects and decodes Random Access Response (RAR) message.
• UETracker: Tracks the connection between the UE and the base station.
• UE DL Worker: Decodes messages sent from the base station to the UE.
• GNB UL Worker: Decodes messages sent from the UE to the base station.
• GNB DL Injector: Encodes and injects messages to the UE.

Figure 2: Components of SNI5GECT (figure reproduced with permission from ASSET Research Group) [1]

While the SNI5GECT framework has had a few modules integrated (e.g. 5Ghoul, Registration Reject, Fingerprinting, etc), I wanted to briefly highlight the new multi-stage downgrade attack (issued with CVD-2024-0096) that was discovered while SNI5GECT was being developed. Firstly, using SNI5GECT, a legitimate Authentication Request from the base station to the UE is captured. The Authentication Request message is replayed, albeit containing an invalid sequence number (SQN). According to the 3rd Generation Partnership Project (3GPP) specification, once the UE receives such replayed message, the UE replies with an Authentication Failure message, starts timer T3520 (a timer used in 5G mobile networks during the authentication and key agreement (AKA) procedure for emergency services) and denylists (i.e., mark as barred) the currently connected 5G gNB if the authentication procedure is not completed before expiry of such timer or the authentication procedure keeps failing. Once the UE denies the gNB and if no other gNB with a different set of configuration is around, it disconnects from 5G and connects to a nearby 4G eNB with the same Mobile Country Code (MCC) and Mobile Network Code (MNC) as the previously connected gNB instead. Furthermore, if no 4G eNBs are available, the UE does not attempt to connect to the same gNB even after waiting a long time. To prevent the gNB from retrying the authentication procedure, SNI5GECT injects the replayed Authentication Request message immediately after the Registration Request message. It continues to do so after receiving any Authentication Failure message from the UE. This forces the UE to drop the connection and denylist the gNB regardless of subsequent attempts from the gNB to continue with the authentication procedure.

There are some current limitations for the SNI5GECT framework. It currently only supports 5G and downlink injection, but can accept extensions as it has a modular design. The accuracy of sniffing and injection are affected by distance (and other factors like dense environments) between the device running SNI5GECT and the target UEs. SNI5GECT also cannot exploit any 5G post-authentication messages due to usage of encrypted messages by design. UEs that have had current connections (post-Random Access Response (RAR) state) with a gNB node would not have their traffic sniffed since SNI5GECT relies on tracking the UE’s Radio Network Temporary Identifier (RNTI) from the start of the Physical Random Access Channel (PRACH) procedure. Finally, SNI5GECT is unable to distinguish a smartphone model or user (i.e., victim UE) solely based on the RNTI to launch targeted attacks. Although it may appear that there are quite a number of limitations, there is currently no open-source alternatives that offer the capabilities that SNI5GECT present.

SNI5GECT can be used with Software Defined Radios (SDR) such as the USRP B210 SDR or USRP x310 SDR, and it is recommended that the host machine has minimally a 12-core CPU with 16GB of RAM. The full technical details of SNI5GECT can be found here [1], and also available as a downloadable PDF file [2].

References:
[1] https://ift.tt/bjg61oy
[2] https://ift.tt/CZWqhgr

———–
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter

(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/dMRB2rO
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/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