AWS Weekly Roundup: Claude Mythos Preview in Amazon Bedrock, AWS Agent Registry, and more (April 13, 2026)

This post was originally published on this site

In my last Week in Review post, I mentioned how much time I’ve been spending on AI-Driven Development Lifecycle (AI-DLC) workshops with customers this year. A common theme in those sessions is the need for better cost visibility. Teams are moving fast with AI, but as they go from experimenting to full production, finance and leadership really need to know who is using which resources and at what cost. That’s why I was so excited to see the launch of Amazon Bedrock new support for cost allocation by IAM user and role this week. This lets you tag IAM principals with attributes like team or cost center and then activate those tags in your Billing and Cost Management console. The resulting cost data flows into AWS Cost Explorer and the detailed Cost and Usage Report, giving you a clear line of sight into model inference spending. Whether you’re scaling agents across teams, tracking foundation model use by department, or running tools like Claude Code on Amazon Bedrock, this new feature is a game changer for tracking and managing your AI investments. You can get all the details on setting this up in the IAM principal cost allocation documentation.

Now, let’s get into this week’s AWS news…

Headlines
Amazon Bedrock now offers Claude Mythos Preview Anthropic’s most sophisticated AI model to date is now available on Amazon Bedrock as a gated research preview through Project Glasswing. Claude Mythos introduces a new model class focused on cybersecurity, capable of identifying sophisticated security vulnerabilities in software, analyzing large codebases, and delivering state of the art performance across cybersecurity, coding, and complex reasoning tasks. Security teams can use it to discover and address vulnerabilities in critical software before threats emerge. Access is currently limited to allowlisted organizations, with Anthropic and AWS prioritizing internet critical companies and open source maintainers.

AWS Agent Registry for centralized agent discovery and governance now in preview AWS launched Agent Registry through Amazon Bedrock AgentCore, providing organizations with a private catalog for discovering and managing AI agents, tools, skills, MCP servers, and custom resources. The registry helps teams locate existing capabilities rather than duplicating them, with semantic and keyword search, approval workflows, and CloudTrail audit trails. It is accessible via the AgentCore Console, AWS CLI, SDK, and as an MCP server queryable from IDEs.

Last week’s launches
Here are some launches and updates from this past week that caught my attention:

  • Announcing Amazon S3 Files, making S3 buckets accessible as file systems — Amazon S3 Files transforms S3 buckets into shared file systems that connect any AWS compute resource directly with your S3 data. Built on Amazon EFS technology, it delivers full file system semantics with low latency performance, caching actively used data and providing multiple terabytes per second of aggregate read throughput. Applications can access S3 data through both file system and S3 APIs simultaneously without code modifications or data migration.
  • Amazon OpenSearch Service supports Managed Prometheus and agent tracing —Amazon OpenSearch Service now provides a unified observability platform that consolidates metrics, logs, traces, and AI agent tracing into a single interface. The update includes native Prometheus integration with direct PromQL query support, RED metrics monitoring, and OpenTelemetry GenAI semantic convention support for LLM execution visibility. Operations teams can correlate slow traces to logs and overlay Prometheus metrics on dashboards without switching between tools.
  • Amazon WorkSpaces Advisor now available for AI powered troubleshooting— AWS launched Amazon WorkSpaces Advisor, an AI powered administrative tool that uses generative AI to help IT administrators troubleshoot Amazon WorkSpaces Personal deployments. It analyzes WorkSpace configurations, detects problems automatically, and provides actionable recommendations to restore service and optimize performance.
  • Amazon Braket adds support for Rigetti’s 108 qubit Cepheus QPU — Amazon Braket now offers access to Rigetti’s Cepheus-1-108Q device, the first 100+ qubit superconducting quantum processor on the platform. The modular design features twelve 9 qubit chiplets with CZ gates that offer enhanced resilience to phase errors. It supports multiple frameworks including Braket SDK, Qiskit, CUDA-Q, and Pennylane, with pulse level control for researchers.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news
Here are some additional posts and resources that you might find interesting:

Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:

  • What’s Next with AWS (April 28, Virtual) Join this livestream at 9am PT for a candid discussion about how agentic AI is transforming how businesses operate. Featuring AWS CEO Matt Garman, SVP Colleen Aubrey, and OpenAI leaders discussing emerging agent capabilities, Amazon’s internal experiences, and new agentic solutions and platform capabilities.

Browse here for upcoming AWS led in person and virtual events, startup events, and developer focused events.


That’s all for this week. Check back next Monday for another Weekly Roundup!

~ micah

Scans for EncystPHP Webshell, (Mon, Apr 13th)

This post was originally published on this site

Last week, I wrote about attackers scanning for various webshells, hoping to find some that do not require authentication or others that use well-known credentials. But some attackers are paying attention and are deploying webshells with more difficult-to-guess credentials. Today, I noticed some scans for what appears to be the "EncystPHP" web shell. Fortinet wrote about this webshell back in January. It appears to be a favorite among attackers compromising vulnerable FreePBX systems.

PowerShell MSI package deprecation and preview updates

This post was originally published on this site

Beginning with PowerShell 7.7-preview.1 (April 2026), the MSIX package will be the primary
installation method for PowerShell on Windows. We will no longer ship the MSI installer package for
new PowerShell releases.

For existing releases, including PowerShell 7.6, we will continue to provide MSI packages. However,
MSI isn’t planned for future releases, including PowerShell 7.7 GA and beyond.

Why we’re making this change

MSIX provides a modern installation and servicing model and is supported by Windows deployment
tools. It uses a declarative model that’s more predictable and reliable than MSI, which relies on
custom actions and scripts that can lead to inconsistent behavior. MSIX supports built-in update
mechanisms with differential updates. Microsoft is investing in improving MSIX.

MSI is a legacy technology. Servicing MSI installations requires external tooling and often results
in full reinstalls. MSI doesn’t meet modern accessibility requirements, particularly for screen
reader scenarios. To be accessible, MSI must present predictable tab stops and accurate
announcements for screen readers, which it doesn’t. Accessibility is a core requirement for
PowerShell.

This decision isn’t just about modernizing packaging for its own sake. It’s about ensuring that
PowerShell installations are modern and accessible for all users, now and in the future.

Looking forward

Our goal is to provide a fully accessible, reliable, and enterprise-ready installation experience.
At this time, MSIX doesn’t support all use case scenarios that MSI enabled, such as remoting and
execution by system-level services (like Task Scheduler). We recognize this gap and are actively
working to address it.

As part of this work, we’re investing in:

  • Improving MSIX support for system-level and enterprise deployment scenarios
  • Ensuring accessibility requirements are fully met across all installation paths
  • Providing clearer guidance and tooling for deployment at scale

We will continue to share updates as this work progresses.

Closing

We understand this change may require adjustments, especially in environments that rely heavily on
MSI-based deployment. We appreciate your patience as we make this transition.

Our focus is to ensure PowerShell remains accessible, predictable, and practical for all users.

— The PowerShell Team

The post PowerShell MSI package deprecation and preview updates appeared first on PowerShell Team.

Number Usage in Passwords: Take Two, (Thu, Apr 9th)

This post was originally published on this site

In a previous diary [1], we looked to see how numbers were used within passwords submitted to honeypots. One of the items of interest was how dates, and more specifically years, were represented within the data and how that changed over time. It is often seen that years and seasons are used in passwords, especially when password change requirements include frequenty password changes. Some examples we might see today:

TeamPCP Supply Chain Campaign: Update 007 – Cisco Source Code Stolen via Trivy-Linked Breach, Google GTIG Tracks TeamPCP as UNC6780, and CISA KEV Deadline Arrives with No Standalone Advisory, (Wed, Apr 8th)

This post was originally published on this site

This is the seventh update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 006 covered developments through April 3, including the CERT-EU European Commission breach disclosure, ShinyHunters' confirmation of credential sharing, Sportradar breach details, and Mandiant's quantification of 1,000+ compromised SaaS environments. This update consolidates five days of intelligence from April 3 through April 8, 2026.

More Honeypot Fingerprinting Scans, (Wed, Apr 8th)

This post was originally published on this site

One question that often comes up when I talk about honeypots: Are attackers able to figure out if they are connected to a honeypot? The answer is pretty simple: Yes!

Most "medium interaction" honeypots, like the one we are using, are just simulating various systems. These simulations are incomplete. For example, we are using the "Cowrie" honeypot to emulate SSH and telnet servers. Once an attacker is connected, any package they are installing will appear to install. In the past, I have written about attackers attempting to install bogus packages. If the install appears to succeed, the attacker knows they are connected to a honeypot. Some attackers look for SSH artifacts, such as the number and types of ciphers supported by SSH.

Today, I noticed one attacker, (IP address %%ip:45.135.194.48%%), using another common trick: Cowrie will often allow attackers to connect "randomly". The effect is that various username and password combinations appear to work. In this case, the attacker used usernames and passwords that are highly unlikely to work. If they succeed, they know they are connected to a honeypot. Here are some of the usernames and passwords used:

username password
admin definitely_not_valid_creds
honeypot indexer
honeypotter imaginegettingindexed
xXhoneypotXx P@ssw0rd1337!
youjustgotindexed getindexedretard

Will we do anything to block these types of requests? Maybe… I am not sure it is important enough to "hide" honeypots. One advantage we have is that many of our honeypots are connected to home networks with dynamic IPs. As a result, any IP address list an attacker will create is somewhat ephemeral. Secondly, we are mostly interested in internet-wide scans. We are not going to detect targeted attacks or zero days. 


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.

Launching S3 Files, making S3 buckets accessible as file systems

This post was originally published on this site

I’m excited to announce Amazon S3 Files, a new file system that seamlessly connects any AWS compute resource with Amazon Simple Storage Service (Amazon S3).

More than a decade ago, as an AWS trainer, I spent countless hours explaining the fundamental differences between object storage and file systems. My favorite analogy was comparing S3 objects to books in a library (you can’t edit a page, you need to replace the whole book) versus files on your computer that you can modify page by page. I drew diagrams, created metaphors, and helped customers understand why they needed different storage types for different workloads. Well, today that distinction becomes a bit more flexible.

With S3 Files, Amazon S3 is the first and only cloud object store that offers fully-featured, high-performance file system access to your data. It makes your buckets accessible as file systems. This means changes to data on the file system are automatically reflected in the S3 bucket and you have fine-grained control over synchronization. S3 Files can be attached to multiple compute resources enabling data sharing across clusters without duplication.

Until now, you had to choose between Amazon S3 cost, durability, and the services that can natively consume data from it or a file system’s interactive capabilities. S3 Files eliminates that tradeoff. S3 becomes the central hub for all your organization’s data. It’s accessible directly from any AWS compute instance, container, or function, whether you’re running production applications, training ML models, or building agentic AI systems.

You can access any general purpose bucket as a native file system on your Amazon Elastic Compute Cloud (Amazon EC2) instances, containers running on Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Kubernetes Service (Amazon EKS), or AWS Lambda functions. The file system presents S3 objects as files and directories, supporting all Network File System (NFS) v4.1+ operations like creating, reading, updating, and deleting files.

As you work with specific files and directories through the file system, associated file metadata and contents are placed onto the file system’s high-performance storage. By default, files that benefit from low-latency access are stored and served from the high performance storage. For files not stored on high performance storage such as those needing large sequential reads, S3 Files automatically serves those files directly from Amazon S3 to maximize throughput. For byte-range reads, only the requested bytes are transferred, minimizing data movement and costs.

The system also supports intelligent pre-fetching to anticipate your data access needs. You also have fine-grained control over what gets stored on the file system’s high performance storage. You can decide whether to load full file data or metadata only, which means you can optimize for your specific access patterns.

Under the hood, S3 Files uses Amazon Elastic File System (Amazon EFS) and delivers ~1ms latencies for active data. The file system supports concurrent access from multiple compute resources with NFS close-to-open consistency, making it ideal for interactive, shared workloads that mutate data, from agentic AI agents collaborating through file-based tools to ML training pipelines processing datasets.

Let me show you how to get started.
Creating my first Amazon S3 file system, mounting, and using it from an EC2 instance is straightforward.

I have an EC2 instance and a general purpose bucket. In this demo, I configure an S3 file system and access the bucket from an EC2 instance, using regular file system commands.

For this demo, I use the AWS Management Console. You can also use the AWS Command Line Interface (AWS CLI) or infrastructure as code (IaC).

Here is the architecture diagram for this demo.

S3 Files demo architectureStep 1: Create an S3 file system.

On the Amazon S3 section of the console, I choose File systems and then Create file system.

S3 Files create file system

I enter the name of the bucket I want to expose as a file system and choose Create file system.

S3 Files create file system, part 2

Step 2: Discover the mount target.

A mount target is a network endpoint that will live in my virtual private cloud (VPC). It allows my EC2 instance to access the S3 file system.

The console creates the mount targets automatically. I take notes of the Mount target IDs on the Mount targets tab.

When using the CLI, two separate commands are necessary to create the file system and its mount targets. First, I create the S3 file system with create-file-system. Then, I create the mount target with create-mount target.

Step 3: Mount the file system on my EC2 instance.

After it’s connected to an EC2 instance, I type:

sudo mkdir /home/ec2-user/s3files sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files

I can now work with my S3 data directly through the mounted file system in ~/s3files, using standard file operations.

When I make updates to my files in the file system, S3 automatically manages and exports all updates as a new object or a new version on an existing object back in my S3 bucket within minutes.

Changes made to objects on the S3 bucket are visible in the file system within a few seconds but can sometimes take a minute or longer.

# Create a file on the EC2 file system 
echo "Hello S3 Files" > s3files/hello.txt 

# and verify it's here 
ls -al s3files/hello.txt
 -rw-r--r--. 1 ec2-user ec2-user 15 Oct 22 13:03 s3files/hello.txt 

# See? the file is also on S3 
aws s3 ls s3://s3files-aws-news-blog/hello.txt 
2025-10-22 13:04:04 15 hello.txt 

# And the content is identical! 
aws s3 cp s3://s3files-aws-news-blog/hello.txt . && cat hello.txt
Hello S3 Files

Things to know
Let me share some important technical details that I think you’ll find useful.

Another question I frequently hear in customer conversations is about choosing the right file service for your workloads. Yes, I know what you’re thinking: AWS and its seemingly overlapping services, keeping cloud architects entertained during their architecture review meetings. Let me help demystify this one.

S3 Files works best when you need interactive, shared access to data that lives in Amazon S3 through a high performance file system interface. It’s ideal for workloads where multiple compute resources—whether production applications, agentic AI agents using Python libraries and CLI tools, or machine learning (ML) training pipelines—need to read, write, and mutate data collaboratively. You get shared access across compute clusters without data duplication, sub-millisecond latency, and automatic synchronization with your S3 bucket.

For workloads migrating from on-premises NAS environments, Amazon FSx provides the familiar features and compatibility you need. Amazon FSx is also ideal for high-performance computing (HPC) and GPU cluster storage with Amazon FSx for Lustre. It’s particularly valuable when your applications require specific file system capabilities from Amazon FSx for NetApp ONTAP, Amazon FSx for OpenZFS, or Amazon FSx for Windows File Server.

Pricing and availability
S3 Files is available today in all commercial AWS Regions.

You pay for the portion of data stored in your S3 file system, for small file read and all write operations to the file system, and for S3 requests during data synchronization between the file system and the S3 bucket. The Amazon S3 pricing page has all the details.

From discussions with customers, I believe S3 Files helps simplify cloud architectures by eliminating data silos, synchronization complexity, and manual data movement between objects and files. Whether you’re running production tools that already work with file systems, building agentic AI systems that rely on file-based Python libraries and shell scripts, or preparing datasets for ML training, S3 Files lets these interactive, shared, hierarchical workloads access S3 data directly without choosing between the durability of Amazon S3 and cost benefits and a file system’s interactive capabilities. You can now use Amazon S3 as the place for all your organizations’ data, knowing the data is accessible directly from any AWS compute instance, container, and function.

To learn more and get started, visit the S3 Files documentation.

I’d love to hear how you use this new capability. Feel free to share your feedback in the comments below.

— seb

A Little Bit Pivoting: What Web Shells are Attackers Looking for?, (Tue, Apr 7th)

This post was originally published on this site

Webshells remain a popular method for attackers to maintain persistence on a compromised web server. Many "arbitrary file write" and "remote code execution" vulnerabilities are used to drop small files on systems for later execution of additional payloads. The names of these files keep changing and are often chosen to "fit in" with other files. Webshells themselves are also often used by parasitic attacks to compromise a server. Sadly (?), attackers are not always selecting good passwords either. In some cases, webshells come with pre-set backdoor credentials, which may be overlooked by a less sophisticated attacker. 

How often are redirects used in phishing in 2026?, (Mon, Apr 6th)

This post was originally published on this site

In one of his recent diaries, Johannes discussed how open redirects are actively being sought out by threat actors[1], which made me wonder about how commonly these mechanisms are actually misused…

Although open redirect is not generally considered a high-impact vulnerability on its own, it can have multiple negative implications. Johannes already covered one in connection with OAuth flows, but another important (mis)use case for them is phishing.

The reason is quite straightforward – links pointing to legitimate domains (such as google.com) included in phishing messages may appear benign to recipients and can also evade simpler e-mail scanners and other detection mechanisms.

Even though open redirect has not been listed in OWASP Top 10 for quite some time, it is clear that attackers have never stopped looking for it or using it. If I look at traffic on almost any one of my own domains, hardly a month goes by when I don’t see attempts to identify potentially vulnerable endpoints, such as:

/out.php?link=https://domain.tld/

While these attempts are not particularly frequent, they are generally consistent.

We also continue to see open redirect used in phishing campaigns. Last year, I wrote about a campaign using a “half-open” (i.e., easily abusable) redirect mechanism on Google [2], and similar cases still seem to appear regularly.

But how regular are they, actually?

To find out, I reviewed phishing e-mails collected through my own filters and spam traps, as well as samples sent to us here at the ISC (either by our professional colleagues, or by threat actors themselves), over the first quarter of this year. Although the total sample only consisted of slightly more than 350 individual messages (and is therefore far from statistically representative), it still provided quite interesting results.

Redirect-based phishing accounted for a little over 21 % of all analyzed messages sent out over the first 3 months of 2026 – specifically for 32 % in January, 18 % in February and 16.5 % in March.

It should be noted that if a message contained multiple malicious links and at least one of them used a redirect, the entire message was counted exclusively as a redirect sample, and that not all redirect cases were classic "open redirects". In fact, the abused redirect mechanisms varied widely.

Some behaved similarly to the aforementioned Google-style “half-open” redirects (see details below), while others were fully open. In some cases, the redirectors were part of tracking or advertising systems, while in others, they were implemented as logout endpoints or similar mechanisms. It should be noted that URL shorteners were also counted as redirectors (although these were not particularly common).

As we mentioned, the Google-style redirects are not fully open. They do require a specific valid token to work, however, since these tokens are typically reusable, have a very long lifetime, and are not tied to any specific context (such as IP address or session), they can be – and are – readily reused in phishing campaigns.

An example of such a phishing message and subsequent redirection can be seen in the following images. Though, to avoid focusing solely on Google, it should be mentioned that similar redirect mechanisms on other platforms (e.g., Bing) are also being abused in the same way.

As we can see, although open redirect is commonly considered more of a nuisance issue than an actual high-risk vulnerability these days, it doesn’t keep malicious actors from misusing it quite heavily… Which means we shouldn’t just ignore it.

At the very least, it is worth ensuring that our own applications do not expose endpoints that can be misused in this way. And where any redirection functionality is strictly required, it should be monitored for abuse and restricted as necessary.

[1] https://isc.sans.edu/diary/Open+Redirects+A+Forgotten+Vulnerability/32742
[2] https://isc.sans.edu/diary/Another+day+another+phishing+campaign+abusing+googlecom+open+redirects/31950

———–
Jan Kopriva
LinkedIn
Nettles Consulting

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