Macfinger ClickFix campaign, (Tue, Sep 22nd)

September 22, 2026 David Leave a comment

This post was originally published on this site

Introduction

I've found several legitimate websites with injected script for a campaign using the ClickFix social engineering technique. This particular ClickFix campaign was documented earlier this month on the Ransom-ISAC Blog, but it doesn't appear to have a nickname yet. Since this campaign is targeting macOS environments through a fingerprinting process, I'm calling it the "Macfinger ClickFix" campaign. No, this is not related to the MacFinger utility from decades ago. Instead, think of the movie Goldfinger, but with macOS malware and the internet instead of James Bond and Miss Galore.

Shown above: An image I created to represent the Macfinger ClickFix campaign.

Today's diary presents indicators from the Macfinger ClickFix campaign that I saw on Tuesday, 2026-09-22.

Images From the Infection

Shown above: First part of the Macfinger injected script in a page from a legitimate website.

Shown above: Second part of the Macfinger injected script in a page from a legitimate website.

Shown above: Fake bot protection page caused by the injected Macfinger script.

Shown above: ClickFix instructions from fake verification pop-up caused by the injected Macfinger script.

While displaying the fake bot protection page with the verification instructions, the Macfinger domain receives frequent POST requests from the victim host. These report information on the user and track the user actions. Here's an example of a POST request through HTTPS traffic after the user has clicked on the page. In this case, the user abandoned the page without following the instructions.

Shown above: POST request over HTTPS to the Macfinger domain reporting the user information.

I had tested one of the Macfinger-infected sites on Monday, 2026-09-21 which had the same post-infection traffic that I saw the next day on Tuesday, 2026-09-22. The image below shows an example of the infection traffic, with the malware files retrieved from 45.150.33[.]128 and the post-infection C2 traffic on 95.163.153[.]80 over TCP port 8133.

Shown above: Traffic from an infection filtered in Wireshark.

Indicators of Compromise

The following are indicators from Tuesday, 2026-09-22.

Traffic to the Macfinger domain:

hxxps[:]//velvet-otter-glagceis[.]life/t.js?site=4f0529f47320472732961318d7d0dfd1
hxxps[:]//velvet-otter-glagceis[.]life/t.4b1009ff6c3f.js
hxxps[:]//velvet-otter-glagceis[.]life/ext-b.4f9db6afd06a.js
hxxps[:]//velvet-otter-glagceis[.]life/collect
hxxps[:]//velvet-otter-glagceis[.]life/collect
hxxps[:]//velvet-otter-glagceis[.]life/collect
hxxps[:]//velvet-otter-glagceis[.]life/collect
hxxps[:]//velvet-otter-glagceis[.]life/collect
hxxps[:]//velvet-otter-glagceis[.]life/collect
hxxps[:]//velvet-otter-glagceis[.]life/collect
hxxps[:]//velvet-otter-glagceis[.]life/collect

ClickFix text from the Macfinger domain, saved to a text file:

SHA-256 hash: 6606a5f18184b224a56c9cb658fa26f7fce45099da548a30a8db2c5f2c70377c

File size: 581 bytes

Initial download:

SHA-256 hash: 9d87b41c2b29ccbeac851b98f1a7dce4ab4781fec0cbc55fa6f93a6299a3d564

File size: 4,674 bytes
File type: Bourne-Again shell script text executable, ASCII text, with very long lines
File location: hxxps[:]//45.150.33[.]128/92961f75b259df2?force=1

Follow-up malware from the above shell script:

SHA-256 hash: b68cdb1b46502fbce67ce3f8110682936d06afd2116af096e30abd4c8376b6dc

File size: 33,285,040 bytes
File type: Mach-O 64-bit executable arm64
File location: hxxps[:]//45.150.33[.]128/d4c8083a7d97?force=1

SHA-256 hash: 1a3765e8cb0055ec31693b8f82ce9744106dee08368259661600b072c6805af4

File size: 34,118,904 bytes
File type: Mach-O 64-bit executable x86_64
File location: hxxps[:]//45.150.33[.]128/2286de55f9afd?force=1

Post-infection Traffic:

2026-09-21 23:12:58 UTC – hxxp[:]//45.150.33[.]128 – GET /92961f75b259df2?force=1
2026-09-21 23:12:59 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:12:59 UTC – hxxp[:]//45.150.33[.]128 – GET /d4c8083a7d97?force=1
2026-09-21 23:13:04 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:05 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:05 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:08 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:08 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:11 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:14 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:15 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:20 UTC – ipinfo[.]io – HTTPS traffic
2026-09-21 23:13:21 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:21 UTC – hxxp[:]//95.163.153[.]80:8133 – GET /api/shell/agent
2026-09-21 23:13:21 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:21 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:22 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:22 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:23 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:23 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:23 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:24 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:26 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:30 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:30 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:30 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:30 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/credentials
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
2026-09-21 23:13:31 UTC – hxxp[:]//95.163.153[.]80:8133 – POST /api/t
And so on…

Final Words

The Ransom-ISAC article on this activity calls the final malware a variant of Atomic macOS (AMOS) Stealer. The indictors I found here don't fully align with the AMOS Stealer activity I've previously reported from a different (non-ClickFix) campaign, so this is a different variant than the AMOS Stealer I've looked into.

For mitigation and protection against Macfinger and other ClickFix campaigns, see guidance from the Microsoft Security Blog.

Macfinger ClickFix seems like a fairly widespread campaign, but I haven't found much about it because 1) it seems relatively new and 2) it's only targeting macOS hosts.

Bradley Duncan
brad [at] malware-traffic-analysis.net

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

AWS

Introducing Amazon CloudWatch Omni: AI-powered observability for generative AI and agentic workloads

September 22, 2026 David Leave a comment

This post was originally published on this site

Today, Amazon CloudWatch introduces CloudWatch Omni, a unified observability experience for application and AI workloads that is app-centric, AI-powered, built on open standards, and delivered off-console. CloudWatch Omni is a purpose-built observability, evaluation, and experimentation solution for AI agents. It helps teams design, evaluate, and operate AI agents across any model provider, framework, or runtime, with an eval-driven workflow, support for the tools you already use, and observability delivered where you work: directly in your IDE and through a standalone web experience, separate from the AWS Management Console.

Organizations deploying agentic AI systems face observability challenges that traditional monitoring can’t address. Agent behavior is non-deterministic: a prompt change can degrade response quality even when standard metrics show no errors. Teams spend hours manually reviewing logs across multiple systems, unable to pinpoint what changed or why. Existing tools force teams to choose between siloed generative AI monitoring or fragmented solutions requiring constant context-switching between their coding environment and browser-based dashboards.

CloudWatch Omni captures every trace and includes built-in evaluators for correctness, coherence, retrieval quality, and tool selection, among others. You can compare prompt versions side by side in the playground, build test datasets from production traffic, run experiments across different configurations, and detect regressions automatically.

Two surfaces for development and operations

CloudWatch Omni delivers observability through two complementary surfaces. Developers get a native extension inside VS Code and Kiro (the currently supported IDEs), where traces appear as you run your agent with a playground and evaluators a click away. Operators get a standalone web experience, separate from the AWS Management Console to monitor the fleet, accessible through SSO with no AWS console needed. Both share the same data: the trace a developer debugs is the trace an operator investigates.

The Cloud Login feature connects your local IDE environment to your AWS account, enabling you to send telemetry data to Amazon CloudWatch for persistent storage, share traces with your team, and access production dashboards. This connection is optional. You can use CloudWatch Omni entirely locally during development, then connect to the cloud when you are ready to monitor agents in production.

Getting started

CloudWatch Omni offers two ways to get started: through the IDE extension (for VS Code and Kiro) or directly through the cloud experience, where you can start sending telemetry data to CloudWatch without installing any IDE extension. In this walkthrough, I install the extension, create an agent, run it, and explore the traces and evaluation tools from my IDE.

After installing the CloudWatch Omni extension from the VS Code Marketplace, the CloudWatch Omni icon appears in the Activity Bar. From the welcome screen, I selected Get started with Sample Project to load a pre-configured agent with sample trace data or use shortcut to Command Palette using Command + Shift + P (on macOS) or Ctrl + Shift + P (on Windows/Linux) and select Omni: Create a new Project

CloudWatch Omni welcome screen and create new project in VS Code

Figure 1. CloudWatch Omni welcome screen & create new project in VS Code

The sample project comes with an agent implementation and example datasets. Part of the getting-started experience is adding OpenTelemetry instrumentation, and CloudWatch Omni guides you through each step. You can also create a new agent from scratch. CloudWatch Omni walks you through the process using an interactive chat where you define the agent’s purpose, select a model provider, and configure tools. All data is stored locally by default. You can optionally connect to AWS to send data to Amazon CloudWatch.

After verifying the configuration, I started the local dev server and sent a question to the agent. What makes this different from a typical chatbot interface is what happens next: selecting View Trace shows exactly how the agent processed the request.

CloudWatch Omni guides your AI code assistant to configure the development environment

Figure 2. CloudWatch Omni guides your AI code assistant to configure the local development environment for testing

CloudWatch Omni integrates with AI code assistants such as Kiro, Claude Code, and Codex to streamline the setup process. These assistants can configure the Dev Server, install dependencies, and set up instrumentation on your behalf, so you can go from installation to running your first traced agent session in minutes without manual configuration.

Figure 3. Interacting with the agent and viewing traces

Traces are essential for understanding AI agent behavior. Unlike traditional request-response systems, agents make multiple decisions per invocation: choosing tools, composing prompts, and chaining sub-calls. Without full trace visibility, diagnosing why an agent produced an incorrect answer or took an unexpected path becomes guesswork. CloudWatch Omni records every step in a structured timeline so you can pinpoint exactly where behavior diverged.

The Trace Explorer shows a detailed breakdown of every step the agent took (LLM calls, tool invocations, and reasoning steps) in a structured, hierarchical timeline. I could drill into any span to inspect inputs, outputs, token usage, and latency.

Trace Explorer showing the agent execution timeline

Figure 4. Trace Explorer showing the agent’s execution timeline

The Trace Explorer also supports Compare mode, which places two traces side by side to see how different prompts or configurations affect behavior. Compare mode is especially helpful when debugging regressions. And with Ask Assistant, an AI agent analyzes your traces to surface patterns and anomalies, answering questions like “Why did the agent call this tool twice?”

Figure 5. Comparing two traces side by side

Evaluation is what turns observability into actionable quality improvement for generative AI. Traditional metrics like latency and error rate cannot tell you whether an agent’s response was helpful, coherent, or factually correct. Evaluators score each response against quality dimensions, letting you measure what users actually experience and catch regressions that standard monitoring misses entirely.

CloudWatch Omni includes 17 built-in evaluators for metrics like coherence, helpfulness, faithfulness, and routing correctness. I selected traces from the Trace Explorer, chose evaluators, and ran an evaluation, getting per-example scores and aggregate metrics without building any custom evaluation framework.

Figure 6. Running evaluations on traces

From there, I used the Playground to test different system prompts side by side, comparing multiple model and prompt configurations in real time to see how each variation affects output quality before committing changes. With the Experiments view, I could run the same dataset against two agent variants and compare their evaluation scores, latency, and token usage side by side to pick the best-performing configuration.

Figure 7. Comparing evaluations across agent variants in the Omni Experiments console

With Prompt Management, you can version and track prompt configurations over time, making it easy to roll back when a new version underperforms.

CloudWatch Omni also provides a Session Explorer to review full conversation histories and understand how agents handle multi-turn interactions, along with an Agent Topology view that visualizes the architecture of your agent system, including sub-agents, tools, and their interconnections. You can drill into any node to inspect performance and identify bottlenecks.

CloudWatch Omni also offers a dedicated web experience accessible from any browser without an IDE. Teams can access all capabilities collaboratively, including application monitoring, analytics, agent observability, and AI-powered investigations.

Figure 8. CloudWatch Omni web experience with application monitoring, analytics, and agent observability

I curated traces into golden datasets for structured experimentation. The Experiment function runs the agent against a dataset and automatically scores results, creating benchmarks for regression testing whenever prompts or agent logic change.

If you already have an agent built with a supported framework, CloudWatch Omni provides two paths to add instrumentation: Auto-instrument with Kiro, which detects your framework and configures tracing automatically, or manual instrumentation with ready-to-use code snippets for Python and TypeScript. For detailed instrumentation guides, see the CloudWatch Omni documentation.

Supported frameworks and open standards

The walkthrough above uses the sample project, but CloudWatch Omni works with the agent frameworks teams are already using: LangChain, LangGraph, CrewAI, OpenAI SDK, Strands, Vercel AI SDK, and more, in both Python and TypeScript. It also provides native observability for agents built with Amazon Bedrock AgentCore, and uses AgentCore’s evaluation capabilities to assess agent quality directly within the Omni workflow.

Instrumentation uses open standards (OpenInference and ADOT), whether your agents run on Lambda, ECS, EKS, or other clouds. For evaluation, Omni integrates with third-party evaluators including Braintrust, DeepEval, and Ragas, alongside built-in datasets, a playground, and batch experiments. No re-platforming required.

CloudWatch Omni brings agent observability and application observability together in a single experience. For the application observability experience, read the companion post Introducing Amazon CloudWatch Omni: collaborative AI-powered observability for your applications.

Pricing and availability

Amazon CloudWatch Omni is now generally available. The IDE extension is free to use. You don’t need an AWS account to get started. You only need AWS credentials for Amazon Bedrock models, or API keys for other providers like OpenAI or Anthropic. Get started today by installing the extension from the VS Code Marketplace.

To explore all capabilities and get started quickly, visit CloudWatch on AWS Builder Center.

If you want to call APIs, search documentation, find regional availability, and check troubleshooting about this feature, try using the AWS MCP Server and plugins with your preferred AI tool. Share your feedback on AWS re:Post or reach out through your usual AWS Support contacts.

Happy building!

— Daniel Abib

Security

The Truth about GET and HTTP Standards, (Tue, Sep 22nd)

September 22, 2026 David Leave a comment

This post was originally published on this site

On Friday, Xavier talked about the newly introduced HTTP Query method. This new method was introduced to allow "GET" requests that include a body. The main reason for this was that GET requests typically do not contain a body. But what if they do?

AWS

AWS Weekly Roundup: AWS Builder Center mobile apps, Amazon Connect Talent GA, Amazon Corretto 27, and more (September 21, 2026)

September 21, 2026 David Leave a comment

This post was originally published on this site

Living in the Netherlands, I spend a fair amount of time on trains, and that is usually where I catch up on what the builder community is writing. Until now, that meant opening a laptop or squinting at a browser tab on my phone. This week I found myself scrolling through trending articles and checking a workshop from the AWS Builder Center mobile app while waiting for a delayed train, and it made those spare twenty minutes very useful. That is why I am glad to open this week with the Builder Center mobile app.

AWS Builder Center is now available as a mobile app on iOS and Android, extending the experience beyond desktop and web. Using your AWS Builder ID, you stay signed in across sessions and can browse trending articles, access 600+ AWS Skill Builder courses, and manage hands-on workshops with free sandbox environments from your mobile device. You can follow AWS Heroes, Community Builders, and User Group Leaders, check Builder Loft event calendars on the go, and receive push notifications for subscribed topics and communities. The app also supports the Wishlist feature for submitting product feedback directly to AWS teams. It is available worldwide on the Apple App Store and Google Play Store.

Builder Center also added two features this week. Polls give you a way to ask the community a question from the Home feed: write a question, add 2 to 5 answer options, set a deadline, and people vote, with results updating live and discussion happening in the comments. Votes are anonymous, and creators see aggregate counts and percentages only. Separately, the Zero to Shipped hackathon is open from September 18 to October 2. You connect your coding agent to AWS, build a real application, and ship it live on AWS for a chance to win a share of a $28,000 prize pool. Five winning projects each receive $5,000 in AWS credits and an AWS Builder swag bundle.

Last week’s launches

Here is what else happened this week.

Amazon Connect Talent is now generally available – Amazon Connect Talent is an AI-powered hiring solution for talent acquisition teams managing hiring at scale. Informed by decades of Amazon hiring science, it uses AI agents to conduct structured voice interviews, administer evidence-based assessments, and score candidates consistently, so recruiters can focus on final decisions. Candidates interview 24/7 from any device, and recruiters review scores, transcripts, and detailed evaluations the next morning. All candidate data is anonymized during AI evaluation, each competency is scored against a rubric with every score tied to specific evidence from the interview, and recruiters keep final decision authority over every hire. General availability includes competency-based assessments, AI-led voice interviews with adaptive questioning, a brand-customizable mobile-first candidate portal, and admin onboarding tools.
Amazon Corretto 27 is now generally available – Amazon Corretto 27, a Feature Release version of the no-cost, multi-platform distribution of OpenJDK, is now available for download on Linux, Windows, and macOS, with support through April 2027. Notable features include G1 as the default garbage collector across all environments (JEP 523), post-quantum hybrid key exchange for TLS 1.3 (JEP 527), compact object headers by default for a smaller memory footprint (JEP 534), and JFR in-process data redaction to remove sensitive data from Java Flight Recorder recordings before they leave the JVM (JEP 536). It also continues previews of enhanced pattern matching, structured concurrency, and lazy constants, along with the Vector API incubator.
Kimi K3 by Moonshot AI is now generally available on Amazon Bedrock – Kimi K3 is now available on Amazon Bedrock for coding and knowledge work. According to Moonshot AI, Kimi K3 is its most capable model and the first open model to reach 2.8 trillion parameters. It combines native vision capabilities with a 1-million-token context window, making it well suited to long-running coding sessions across large repositories, multi-document analysis, and extended agent workflows. Moonshot AI reports an approximate 2.5x improvement in scaling efficiency over Kimi K2. Kimi K3 is the first open-weight model on Amazon Bedrock to support explicit prompt caching, which helps reduce latency and input costs when reusing context across model calls.
AWS reimagines the getting started experience – We announced a new simplified experience for builders starting a new project. Instead of completing configuration tasks first, you start with sensible defaults: sign up using an existing identity from providers including Google, GitHub, and Apple, and for most new customers no credit card is required, with $100 in free credits as part of the AWS Free Tier. AWS organizes your work in a project, which contains an AWS account and sharing settings, and applies security controls for you. You can invite collaborators by email without setting up IAM users, set a monthly spend limit starting at $20, and activate advanced AWS features later at no additional cost with no migration. The experience is gradually rolling out to new customers.
New low-cost burstable Amazon EC2 T8i instances are generally available – Amazon EC2 T8i instances, powered by custom sixth-generation Intel Xeon Scalable processors (Granite Rapids), are among the lowest-cost EC2 instances and deliver up to 30% better price performance over previous-generation T3 instances. They are designed for low-to-moderate CPU utilization workloads such as microservices, low-traffic websites, development and testing environments, and small databases. T8i instances deliver up to 70% higher compute performance, up to 1.25x higher network bandwidth, and up to 2.4x higher Amazon EBS bandwidth compared to T3, and they use the same CPU credit system, so upgrading from T3 is straightforward.
AWS Elastic Beanstalk introduces Cluster Mode – AWS Elastic Beanstalk Cluster Mode is a new fully managed option for teams running a portfolio of applications on shared infrastructure powered by Amazon EKS. Instead of operating each application in isolation, you run multiple applications through one experience with a single operational baseline, so per-application cost decreases as your portfolio grows. You can upload source code in Java, .NET, Python, Node.js, PHP, Ruby, or Go, and Elastic Beanstalk handles containerization automatically through Cloud Native Buildpacks when needed. Cluster Mode includes production-grade deployment strategies with automatic rollback, event-driven autoscaling, AWS Secrets Manager integration, native OpenTelemetry observability, and AI-powered troubleshooting. Standard and Cluster Mode environments run side by side within the same application, so teams can migrate one environment at a time.

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 you may find useful:

Building in the AWS European Sovereign Cloud – Two new posts cover building on the AWS European Sovereign Cloud, an independent cloud for Europe that runs as a distinct partition with its own control plane, IAM, billing, console, and service endpoints, and its first Region in Brandenburg, Germany. The first post walks through architecting a secure landing zone, covering account structure and governance, identity as infrastructure as code, centralized logging, data protection, and partition-aware ARN construction that works across AWS partitions. The second announces the general availability of Gemma 4 open-weight models on the Amazon Bedrock next-generation inference engine in the AWS European Sovereign Cloud, with inference staying entirely within eusc-de-east-1 under a zero data retention and zero operator access model.
The new AgentCore runtime: elastic, optimized, and consistently fast starts – We announced a new version of the Amazon Bedrock AgentCore runtime, the managed compute layer for running agents. The new runtime reclaims memory as a session releases it rather than holding it at the peak, so the bill tracks real usage over the life of a session. It also delivers consistent cold start times regardless of container image size or concurrency by preparing the environment once, snapshotting it, and restoring that snapshot for each new instance. In testing with an empty echo agent, the new runtime delivered a P75 cold start of about 2 seconds from a 200 MB image up to 2 GB, compared to roughly 5.4 to nearly 30 seconds for the original runtime.
Introducing the updated AWS Well-Architected Streaming Media Lens – We published a revised Streaming Media Lens, which provides architectural best practices for video streaming workloads. The revision expands from the original 2021 version to cover five streaming scenarios, including interactive live streaming with Amazon IVS Real-Time Streaming for up to 25,000 concurrent viewers, low-latency live streaming, and ad-supported content monetization, alongside enhanced video-on-demand and live streaming guidance. It also adds new sustainability best practices focused on reducing carbon footprint, expanded observability and incident-response frameworks, and advanced content protection with multi-layered DRM and forensic watermarking. The lens whitepaper and custom lens are available now.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Upcoming AWS events

Check your calendar and sign up for upcoming AWS events:

AWS re:Invent – AWS re:Invent returns to Las Vegas from November 30 to December 4. 2, 200+ session times, locations, and speakers are live. Reserved seating for AWS re:Invent opens October 6. Register now and be ready to claim your spot in chalk talks, workshops, and builders’ sessions when reserved seating opens.
AWS Summits – AWS Summits are free in-person events covering cloud and AI. With re:Invent on the horizon, the Summits are coming to an end for the year. The last Summit is Dubai (September 30) at the Dubai World Trade Center, with 60+ sessions, an AWS Village, and hands-on workshops.
AWS Community Days – Community-led conferences planned and delivered by community leaders. Upcoming events include Lebanon (September 26), Malaysia, Kuala Lumpur (September 26), Cebu, Philippines (September 26), Davao, Philippines (September 26), ComSum Manchester, UK (October 1), and Italy, Rome (October 2).

Summer has officially given way to September, but the weather where I am has not quite caught up. The days are still unusually warm, and I suspect these are the last mild afternoons before autumn settles in for good. I am making the most of them while they last. Come back next week for more!

— Esra

Security

TerminalFix: PNG Steganography, (Mon, Sep 21st)

September 21, 2026 David Leave a comment

This post was originally published on this site

Microsoft Security Research published an interesting blog post "TerminalFix campaign deploys a reverse tunnel through multistage intrusion" about a malware campaign. The aspect that I want to take a closer look at, is the fact that the threat actors used PNG files with steganography. I reached out to the researchers and they kindly shared the IOCs for the PNG files with me.

Security

HTTP QUERY Method: The Grey Zone Between GET And POST., (Fri, Sep 18th)

September 18, 2026 David Leave a comment

This post was originally published on this site

In June 2026 the IETF published RFC 10008[1], defining a new HTTP method: "QUERY". The HTTP protocol faced already by changes (HTTP/2, HTTP/2) but it’s the first new standard HTTP verb since "PATCH" in 2010!

AWS

New low-cost burstable Amazon EC2 T8i instances are generally available

September 17, 2026 David Leave a comment

This post was originally published on this site

Today, we’re announcing the general availability of new low-cost burstable Amazon EC2 T8i instances powered by custom sixth generation Intel Xeon Scalable Processors (Granite Rapids), available only on AWS. T8i instances are among the lowest-cost EC2 instances and deliver up to 30% better price performance over previous generation T3 instances. These instances are designed to run a variety of low-to-moderate CPU utilization workloads such as freemium services, training and demo environments, staging and development, data processing, microservices, low-traffic websites, and login gateways.

T8i instances
Thousands and thousands of customers run various lightweight workloads on T3 instances that require small, cost-effective compute configurations. These include microservices architectures, low-traffic websites, development and testing environments, small databases, data processing jobs, and short-duration compute tasks. Many of these customers like T family’s burstable performance model, which provides a baseline level of CPU performance with the ability to burst above the baseline when needed using CPU credits.

As customers modernize their infrastructure, migrate from on-premises environments, adopt event-driven and microservices architectures, and experiment with AI inference workloads, they have asked for newer generation cost-optimized small instances, better price performance to reduce their total cost of ownership, and a seamless migration path that leverages their existing knowledge and tooling.

T8i instances address each of these requests:

Up to 30% better price performance. Powered by the AWS Nitro System and custom sixth generation Intel Xeon Scalable Processors (Granite Rapids), T8i instances enable customers to lower their total cost of ownership with up to 30% better price performance.
Up to 70% higher compute performance. T8i instances deliver up to 70% higher compute performance, up to 1.25x higher network bandwidth, and up to 2.4x higher EBS bandwidth compared to T3 instances.
Seamless upgrade from T3. For existing T3 customers, upgrading to T8i is straightforward. The instances offer the same CPU credit system and the same familiar lightweight compute options customers already know. Customers simply select T8i instead of T3 and immediately benefit from improved price performance.
Cost-effective entry point for new customers. For customers new to AWS or migrating from on-premises, T8i instances provide one of the most cost-effective entry points to run workloads that need low-to-moderate CPU utilization or for running short-duration compute tasks such as batch processing, event-driven functions, or CI/CD pipelines.

Instance specifications
T8i instances offer four sizes, each with two vCPU offered as a single core. The following table summarizes the specifications.

Instance size	vCPUs	Memory (GiB)	Baseline Performance /vCPU (%)	CPU credits earned / hour	Network burst bandwidth (Gbps)
t8i.nano	2	0.25	5	3	Up to 6.25
t8i.micro	2	0.5	10	6	Up to 6.25
t8i.small	2	1	20	12	Up to 6.25
t8i.medium	2	2	20	12	Up to 6.25

Like T3, T8i instances offer unique vCPU-to-memory ratios such as 1:0.25, 1:0.5, and 1:1 that are not offered by other EC2 instances. Like T3, T8i instances utilize the CPU credit system along with the Standard and Unlimited credit configuration modes. Unlimited mode is the default on T8i.

For workloads that need larger instance sizes above T8i offerings (nano, micro, small, and medium), I recommend M8i Flex instances that offer up to 30% better price performance than equivalent previous generation T3 instances along with the flexibility to scale up to 16xlarge.

Now available
Amazon EC2 T8i instances are available today in the following AWS Regions: US East (N. Virginia, Ohio), US West (Oregon, N. California), Asia Pacific (Hyderabad, Malaysia, Mumbai, Seoul, Singapore, Sydney, Tokyo), Canada (Central), and Europe (Frankfurt, Ireland, London, Paris). For Regional availability and upcoming Region expansion, search the instance type in the CloudFormation resources tab of AWS Capabilities by Region.

You can purchase T8i instances via On-Demand instances, and Spot instances with Savings Plan option coming soon. T8i instances support shared tenancy only and do not support Dedicated tenancy or Dedicated Hosts. t8i.micro and t8i.small instances are also available under the AWS Free Tier. To learn more, visit the Amazon EC2 Pricing page.

Try T8i instances in the Amazon EC2 console and send feedback to AWS re:Post for EC2 or through your usual AWS Support contacts.

— Channy

AWS

AWS Elastic Beanstalk introduces Cluster Mode

September 17, 2026 David Leave a comment

This post was originally published on this site

Since the first launch of AWS Elastic Beanstalk in 2011, customers have deployed full-stack applications in Java, .NET, Python, Node.js, PHP, Ruby, and Go, trusting Elastic Beanstalk to manage deployment and infrastructure operations so they could focus on business logic. Fifteen years later, that trust has only deepened, and the service has been rebuilt to match it. Now, AWS Elastic Beanstalk is the application management service on AWS that takes full operational responsibility for your production environments. Bring applications however they exist today: source code, Dockerfiles, or container images. Elastic Beanstalk creates and manages the production environment underneath. You manage your application. AWS manages everything else, deploying, scaling, patching, monitoring, and maintaining it continuously. That operational responsibility stays with AWS, for the life of the application.

We have been rebuilding the operational engine underneath and delivering a series of capabilities that make it more powerful than ever. Elastic Beanstalk now uses AI-powered environment analysis to diagnose health issues and recommend fixes automatically. A new official GitHub Action lets teams deploy directly from their existing CI/CD workflows with a single YAML configuration. And we rebuilt the infrastructure foundation to deliver OpenTelemetry-based observability, traffic-splitting deployments with automatic rollback, event-driven autoscaling, secrets management through AWS Secrets Manager, and HTTPS by default via AWS Certificate Manager.

Today, we’re announcing the next chapter of AWS Elastic Beanstalk: a new fully-managed Cluster Mode that deploys, scales, patches, monitors, and upgrades your applications continuously for the life of the workload. You bring your application. AWS runs it.

A new Cluster Mode is built for teams running a portfolio of applications. Instead of operating each application in isolation, you run multiple applications that share infrastructure powered by Amazon Elastic Kubernetes Service (Amazon EKS), fully managed with a single operational baseline. Multiple applications share resources, so per-application cost decreases as your portfolio grows without adding operational complexity. Whether you run ten applications or a hundred, you manage them through one experience, with the same operational guarantees across every stack.

Elastic Beanstalk Cluster Mode benefits for your workloads:

Source code to production, any runtime. Upload source code in Java, .NET, Python, Node.js, PHP, Ruby, or Go. Elastic Beanstalk handles containerization automatically through Cloud Native Buildpacks when needed. No Dockerfile and no rearchitecting required. You can bring legacy applications from on-premises or deploy new services in any supported language.
Enterprise compliance built in. Elastic Beanstalk is HIPAA eligible, PCI DSS compliant, and aligned to SOC 1/2/3 with no additional configuration, so teams in regulated industries can deploy production workloads with the compliance posture they already require.
Production-grade deployment strategies. All-at-once, rolling, immutable, and traffic-splitting deployments with automatic rollback on failure. Event-driven autoscaling. AWS Secrets Manager integration. All native OpenTelemetry enabling easy integration with most observability backends, including Amazon CloudWatch.
AI-powered troubleshooting. When something goes wrong, Elastic Beanstalk collects service-side logs and provides AI-generated recommendations to help you resolve issues faster without digging through infrastructure.

A first look of Elastic Beanstalk Cluster Mode
To get started, go to the Elastic Beanstalk console, create a new environment, and choose the Cluster in the Deployment type.

Elastic Beanstalk accepts source code, docker file, or container image to deploy your application. For example, you can provide the application code for your environment by selecting Local file and specifying container image build options. For the rest of the sections, the default values should be good for most scenarios.

Choose Create button and the deployment will begin! Note that the first deployment for a given set of subnets triggers EKS cluster creation, which takes about ten-ish minutes. Subsequent deployments are faster because they reuse an existing EKS cluster.

Here’s what it looks like when deployment is successful:

You can also use AWS Command Line Interface (AWS CLI), the EB CLI, or AWS SDKs. For example, consider deploying an application made up of several microservices to Kubernetes. Create an application first.

aws elasticbeanstalk create-application 
    --application-name "my-microservice" 
    --description "Multi-services demo"

Each microservice may have pre-built images in Amazon Elastic Container Registry (Amazon ECR). Register them as application versions:

IMAGES=(
    "frontend-v1|public.ecr.aws/my-microservices/frontend:v1"
    "cartservice-v1|public.ecr.aws/my-microservices/cart:v1"
    "paymentservice-v1|public.ecr.aws/my-microservices/payment:v1"
    "shippingservice-v1|public.ecr.aws/my-microservices/shipping:v1"
)

for entry in "${IMAGES[@]}"; do
    IFS='|' read -r label uri <<< "$entry"
    aws elasticbeanstalk create-application-version 
        --application-name $APP_NAME 
        --version-label "$label" 
        --image-configuration Source="{Uri=$uri}" 
	--region "us-west-2
    echo "Registered: $label"
done

You can set and deploy the corresponding service options for each service. For example, the frontend service is the only service that needs a public internet interface such as Application Load Balancer and also sets a health check path since it’s an HTTP service:

[
    {"Namespace": "aws:elasticbeanstalk:eks", "OptionName": "cluster-role", "Value": "arn:aws:iam::0123456789012:rol<...>"},
    {"Namespace": "aws:elasticbeanstalk:eks", "OptionName": "node-role", "Value": "arn:aws:iam::0123456789012:role/E<...>"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "observability-role", "Value": "arn:aws:iam::0123456<...>"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "subnets", "Value": "subnet-1,subnet-2,subnet-3,<...>"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling", "OptionName": "min-replica", "Value": "1"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling", "OptionName": "max-replica", "Value": "2"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "cpu", "Value": "0.5"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "memory", "Value": "256Mi"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "memory-limit", "Value": "512Mi"},
    {"Namespace": "aws:elasticbeanstalk:eks:environment", "OptionName": "service-port", "Value": "8080"},
    {"Namespace": "aws:elasticbeanstalk:eks:alb", "OptionName": "scheme", "Value": "internet-facing"},
    {"Namespace": "aws:elasticbeanstalk:eks:alb", "OptionName": "healthcheck-path", "Value": "/_healthz"}
] #frontend-options.json namespaces

Now, create the frontend service environment with these options. You can continue to deploy each service environment in a similar manner.

aws elasticbeanstalk create-environment 
    --application-name my-microservice 
    --environment-name frontend 
    --version-label frontend-v1 
    --tier Name=Cluster,Type=EKS 
    --option-settings file:///tmp/frontend-options.json

Here’s a look at the console once all services are deployed:

Elastic Beanstalk Standard powered by Amazon Elastic Compute Cloud (EC2) continues to be fully supported. Standard and Cluster Mode environments run side by side within the same Elastic Beanstalk application, enabling teams to migrate one environment at a time at their own pace. Validation checks confirm compatibility before any changes are made, so no environment is forced to move.

Elastic Beanstalk Standard Mode remains the best fit for:

Single applications or single-environment use cases
Windows/.NET Framework workloads on IIS
Applications that cannot be containerized
Workloads spending under $500/month where the EKS control plane fee and EKS Auto Mode premium add overhead that a single application cannot offset through bin-packing

To learn more about how to deploy and manage your applications in the Cluster Mode, visit the Elastic Beanstalk Cluster Mode documentation.

Now available
AWS Elastic Beanstalk Cluster Mode is generally available today in all AWS Regions that Elastic Beanstalk is available. For Regional availability and a future roadmap, visit the AWS Capabilities by Region. If you want to call APIs, search documentation, find regional availability, and troubleshooting about this new feature, try using the AWS MCP Server and plugins with your preferred AI tool.

There is no additional charge for Elastic Beanstalk Cluster Mode. You pay only for the underlying AWS resources your applications consume, including the EKS control plane fee, EKS Auto Mode compute, Amazon ECR, and Amazon CloudWatch. Note Elastic Beanstalk Cluster Mode is not AWS Free Tier eligible. To learn more, visit the AWS Elastic Beanstalk Pricing page.

Give it a try in the Elastic Beanstalk console and send feedback to AWS re:Post for AWS Elastic Beanstalk or through your usual AWS Support contacts.

— Channy

Security

LausivLoader analysis, or how to pass data between malware stages, (Thu, Sep 17th)

September 17, 2026 David Leave a comment

This post was originally published on this site

At the end of August, a malspam message was caught in the quarantine of a mail gateway operated by one of my customers. The message was not especially remarkable – it asked the recipient to review some attached requirements and provide a price quotation for a fiber optic system and appeared to impersonate an employee of a legitimate company.

Powershell

Announcing Microsoft Desired State Configuration v3.3.0

September 17, 2026 David Leave a comment

This post was originally published on this site

We’re excited to announce the General Availability of Microsoft Desired State Configuration (DSC)
v3.3.0. This release delivers three new built-in Windows resources, a new registry-backed adapter,
expanded --what-if support, experimental export filtering, expression function updates, and Linux
packages published to PMC.

For background on the DSC v3 platform, see:

For information on installing DSC v3.3, see the installation documentation.

What’s New in DSC v3.3

All these changes are driven by real-world use, partner feedback, and community contributions.
Special thanks to the WinGet team and the incredible DSC community.

For a complete list of changes, see the release page on GitHub.

New built-in Windows resources

DSC v3.3 adds three new resources to the Microsoft.Windows namespace.

Microsoft.Windows/RegistryListManages an array of registry entries in a single resource instance, instead of requiring one
Microsoft.Windows/Registry instance per key or value. The underlying registry.exe gained a
--list switch to support it, the resource version moved to 1.1, and the registry manifests were
consolidated into a single registry.dsc.manifests.json file.
Microsoft.Windows/WindowsFeatureListManages Windows features as a list, following the same list-oriented pattern.
Microsoft.Windows/PersonalizationManages Windows personalization settings, including accent color, light and dark mode, and
transparency.

All three ship in the box. You can discover them, and inspect their schemas, with the DSC CLI:

dsc resource list 'Microsoft.Windows/*'
dsc resource schema --resource Microsoft.Windows/Personalization

New adapter: `Microsoft.Windows.Adapter/Registry`

v3.3 introduces Microsoft.Windows.Adapter/Registry, a registry-backed adapter that includes
helpers for converting between JSON property values and their registry representations. This lets a
resource express its desired state as ordinary JSON properties while the adapter handles the
registry read and write.

NOTE

The conversion helpers currently cover the types needed by
Microsoft.Windows/Personalization. We deliberately started narrow rather than guessing at a
complete type mapping up front. We’ll add more conversions as real use cases surface. If you hit a
registry type the adapter doesn’t handle, open an issue. That’s exactly the signal we’re looking
for.

`dsc mcp` is now `dsc server`

The dsc mcp command is renamed to dsc server to better reflect usability. Many of the endpoints
that are useful to MCP clients are also useful to integrating tools and provides a clean API for
functionality that higher order tools can leverage. The mcp name is retained as a
backward-compatible alias, so existing client configurations keep working.

dsc server

Three new tools are available to connected clients in v3.3:

show_dsc_schema() — returns the JSON schema for a DSC resource or type
invoke_dsc_function() — invokes a DSC built-in function
invoke_dsc_expression() — evaluates a DSC expression

Together these let a client inspect what a resource expects and evaluate configuration
expressions without shelling out to the CLI.

`format()` is no longer experimental

The format() expression function graduates to stable in v3.3. It behaves the same as it did in
preview, but the experimental warning is gone and you can rely on it in production configurations.

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Echo formatted message
    type: Microsoft.DSC.Debug/Echo
    properties:
      output: "[format('{0}/{1}', 'Microsoft.Windows', 'Personalization')]"

New expression functions: `stateChanged()` and `restartRequired()`

DSC v3.3 adds two new stable expression functions for reasoning about resource state within a
configuration document:

stateChanged() – returns whether a resource instance changed state during the current set
operation. The input must be the resource ID for another instance in a configuration, like
stateChanged(resourceId('<resourceTypeName>', '<resourceInstanceName>')).
restartRequired() – returns whether a system, service, or process requires a restart. The input
depends on which kind of restart you want to query:
- restartRequired('system') – indicates whether the system itself requires a restart.
- restartRequired('service', '<serviceName>') – indicates whether the specified service
  requires a restart.
- restartRequired('process', '<processName>') – indicates whether the specified process
  requires a restart.

Expanded `--what-if` support

--what-if lets you preview what a set operation would change without modifying your system. In
v3.3, three more resource areas support it.

Microsoft.Windows/Service
Microsoft.Windows/FirewallRuleList
The SSHD config resources

Preview a service change without applying it:

# service.dsc.config.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Print Spooler
    type: Microsoft.Windows/Service
    properties:
      name: Spooler
      startType: Disabled

dsc config set --what-if --file ./service.dsc.config.yaml

DSC reports the state it would set, so you can review the change before committing to it.

Unspecified rules handling for `Microsoft.Windows/FirewallRuleList`

In this release of DSC, the Microsoft.Windows/FirewallRuleList resource added the
unspecifiedRules property to control how DSC treats firewall rules you didn’t list in your
configuration.

The unspecifiedRules property has three fields to provide more fine-grained control:

action (required) – indicates whether the resource should ignore, disable, or remove the
rules.
direction (optional) – limits the action to Inbound or Outbound rules if specified. To apply
the action to all unspecified rules regardless of direction omit this field.
profiles (optional) – limits the action to an array of specified profiles – Domain, Private,
Public, or All.

The following snippet shows an instance of Microsoft.Windows/FirewallRuleList that disables every
inbound rule for the Public profile:

# firewall.dsc.config.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Firewall rules
    type: Microsoft.Windows/FirewallRuleList
    properties:
      rules: [] # Define no rules to apply to _all_ rules
      unspecifiedRules:
        action: disable
        direction: Inbound
        profiles: [Public]

Synthetic export filtering (experimental)

This feature is experimental in v3.3 and its syntax may change in a future release.

Starting with version 3.3.0, the DSC engine supports synthetic export filtering for resources
that don’t directly implement filtering for instances in export operations.

In this release, resources can opt into letting the DSC engine filter the resources returned by the
export operation by defining the export.supportsFiltering field in a resource manifest as
false.

When a resource opts into using synthetic export:

A user defines an input instance of the resource, defining one or more properties to filter the
exported instances on.
DSC invokes the export operation for the resource without passing the defined filtering
properties from the resource instance.
The resource emits the full list of instances to DSC.
The DSC engine uses the defined properties in the resource instance to filter the emitted
instances the resource returned.

The synthetic export filtering in this release has the following limitations:

The provided input for the instance must be an object where every property is a valid
property name for the resource.
The value for every property in the input object must be one of:
- A valid value for the property, which DSC uses for an exact match.
- A string with at least one wildcard character (*), which DSC uses for a case-insensitive
  wildcard match.
When the property is defined in the resource schema as an object you can specify
the subproperties as valid values or wildcard matching strings. DSC applies the filter through
nested layers, enabling you to filter for deeply nested subproperties as well as top-level
properties.
When the property is defined in the resource schema as an array you can specify one or more
items. When you specify multiple items, DSC treats each item as a logical OR filter.
There is no builtin filtering behavior for more complex cases, like version range matching or
minimum/maximum bounds for integer properties.

For example, the following snippet of a configuration document shows how you could export a subset
of Windows services even though Microsoft.Windows/Service doesn’t implement export filtering:

# services.dsc.config.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  # Only exports services where the startup type begins with `auto` and the logon account inludes
  # `local` in the account name
  - name: Automatically starting local account services
    type: Microsoft.Windows/Service
    properties:
      startType: Auto*
      logonAccount: '*Local*'
  # Only exports services that depend on `rpcss` or a service that starts with `w`
  - name: Services depending on RpcSs or a service that starts with w
    type: Microsoft.Windows/Service
    properties:
      dependencies:
        - RpcSs
        - w*
  # Only exports services where the following are all true:
  # - the startup type begins with `auto`
  # - the logon account inludes `local` in the account name
  # - the service depends on `rpcss` or a service that starts with `w`
  - name: Combined service filter
    type: Microsoft.Windows/Service
    properties:
      startType: Auto*
      logonAccount: '*Local*'
      dependencies:
        - RpcSs
        - w*

`--required-version` replaces `--version`

The dsc resource * commands now take --required-version instead of --version. The old flag
is retained as a backward-compatible alias.

The rename better reflects the semantics and usage for the parameter. The previous name,
--version, implied an exact match for a specific version instead of a version requirement, which
is how DSC actually parses and uses the parameter value. You can specify Rust-like semantic version
requirements, like ^1.1, ~1.2.3, and >=1.

dsc resource schema --resource Microsoft.Windows/RegistryList --required-version '^1.1.0'

`Microsoft/OSInfo` version comparison

Microsoft/OSInfo now supports version comparison, so a configuration can assert a version
constraint on the OS rather than matching an exact value. Starting with this release, you can
specify the version field with a comparison operator followed by a full or partial version, like
>10.1. The available comparators are:

Equal to (=) – this is the default comparator, requiring an exact match for the text that
follows the comparator.
Less than (<)
Less than or equal to (<=)
Greater than (>)
Greater than or equal to (>=)

You can only specify a single comparator for the version. You can’t combine them in a single
instance to define a version range. When you specify a comparator other than the equal to comparator
(=), you can specify a partial version to match. For example, if you define the version as > 10
the instance will be valid for any operating system versions like 10.0.1 and 11.3.7.

The comparison works for versions that include non-digit segments but the version must start with
a digit.

Linux packages on PMC

DSC v3.3 is published to the https://packages.microsoft.com (PMC) for Linux as both RPM and DEB
packages. You can now install and update DSC through your distribution’s package manager instead of
downloading a tarball from GitHub releases.

Community contributions

This release leaned heavily on the community, and we’re grateful for it.

@Gijsreyn (Gijs Reijn) was the standout contributor this cycle. Gijs contributed
Microsoft.Windows/WindowsFeatureList, --what-if support for Microsoft.Windows/Service,
Microsoft.Windows/FirewallRuleList, and the SSHD config resources, experimental export filtering,
the graduation of format() out of experimental, category and description filters for the function
list, and a large amount of documentation work. Thank you, Gijs.

@JohnMcPMS (Winget team) contributed a fix for stdin being inherited by child processes
when no input was provided.

@Alex-shearing contributed documentation fixes and documentation for previously
undocumented functions.

@ThomasNieto (Thomas Nieto) added dev container support to the repository, making it
easier to get a working DSC build environment.

Looking ahead

We’ll keep iterating on the platform based on what you tell us — real configurations, real adapters,
and real bug reports shape what we build next. Watch the DSC repository for what’s in flight.

Call to action

Install DSC v3.3.0, try the new Windows resources, and run --what-if against a configuration
before you apply it. If you find a bug, hit a gap in the registry adapter’s type conversions, or
have feedback on experimental export filtering, open an issue in the DSC repository. Community
feedback is what drove this release, and it’s what will drive the next one.

The post Announcing Microsoft Desired State Configuration v3.3.0 appeared first on PowerShell Team.

Iron Castle Systems

Macfinger ClickFix campaign, (Tue, Sep 22nd)

Introducing Amazon CloudWatch Omni: AI-powered observability for generative AI and agentic workloads

The Truth about GET and HTTP Standards, (Tue, Sep 22nd)

AWS Weekly Roundup: AWS Builder Center mobile apps, Amazon Connect Talent GA, Amazon Corretto 27, and more (September 21, 2026)

TerminalFix: PNG Steganography, (Mon, Sep 21st)

HTTP QUERY Method: The Grey Zone Between GET And POST., (Fri, Sep 18th)

New low-cost burstable Amazon EC2 T8i instances are generally available

AWS Elastic Beanstalk introduces Cluster Mode

LausivLoader analysis, or how to pass data between malware stages, (Thu, Sep 17th)

Announcing Microsoft Desired State Configuration v3.3.0

What’s New in DSC v3.3

New built-in Windows resources

New adapter: `Microsoft.Windows.Adapter/Registry`

`dsc mcp` is now `dsc server`

`format()` is no longer experimental

New expression functions: `stateChanged()` and `restartRequired()`

Expanded `--what-if` support

Unspecified rules handling for `Microsoft.Windows/FirewallRuleList`

Synthetic export filtering (experimental)

`--required-version` replaces `--version`

`Microsoft/OSInfo` version comparison

Linux packages on PMC

Community contributions

Looking ahead

Call to action

Iron Castle Systems

What’s New in DSC v3.3

New built-in Windows resources

New adapter: Microsoft.Windows.Adapter/Registry

dsc mcp is now dsc server

format() is no longer experimental

New expression functions: stateChanged() and restartRequired()

Expanded --what-if support

Unspecified rules handling for Microsoft.Windows/FirewallRuleList

Synthetic export filtering (experimental)

--required-version replaces --version

Microsoft/OSInfo version comparison

Linux packages on PMC

Community contributions

Looking ahead

Call to action

Iron Castle Systems

New adapter: `Microsoft.Windows.Adapter/Registry`

`dsc mcp` is now `dsc server`

`format()` is no longer experimental

New expression functions: `stateChanged()` and `restartRequired()`

Expanded `--what-if` support

Unspecified rules handling for `Microsoft.Windows/FirewallRuleList`

`--required-version` replaces `--version`

`Microsoft/OSInfo` version comparison