Security

A Closer Look at Malware From the Macfinger ClickFix Campaign, (Fri, Sep 25th)

Leave a comment
This post was originally published on this site

Introduction

My previous post on Macfinger ClickFix was two days ago, and this campaign remains active. The more I look into the malware delivered by this campaign, the more I believe it is not a variant of Atomic macOS (AMOS) Stealer as originally reported. There are too many differences between what I've documented with recent AMOS Stealer activity and what I'm now seeing with this malware. The data collection and method of exfiltration is different between these two malware families. The persistence mechanism is different. Finally, AMOS Stealer uses an installer with a combined arm64/x86_64 architecture, but this malware uses either an arm64 or an x86_64 Mach-O binary depending on the architecture of the victim's host. There are too many differences with this malware.

The malware delivered by Macfinger ClickFix is indeed an information stealer. I just don't know what to call it.

In an attempt to find out, this diary examines an infection from the Macfinger ClickFix campaign on Thursday, 2026-09-24. This infection was on a physical host running macOS 27.0 (Golden Gate).


Shown above: Example of a fake CAPTCHA/verification page generated in the Macfinger ClickFix campaign.

The Macfinder Domain and ClickFix Text

On Thursday 2026-09-24, the Macfinder domain for the fake verification page was hollow-badger-moasfraum[.]life. The clipboard-injected text was similar to what I reported in my previous diary, and I pasted it into a Terminal window.


Shown above: Clipboard-injected text from the Macfinger ClickFix campaign pasted in a Terminal window.

I saw the same message in my Terminal window after running the ClickFix text as the message noted in the Ransom-ISAC blog.


Shown above: Terminal window after running the ClickFix text.

Loader Activity

The ClickFix text retrieved a loader from hxxp[:]//45.131.215[.]56/8031e818c7a46?force=1. This loader is a shell script, and it saves a binary under the user's /Library/Caches/com.apple.securityd/ directory as com.apple.periodic.

If com.apple.periodic already exists and is running, the script will kill that running process.


Shown above: The initial downloaded shell script showing a location of a binary.

The script checks the system's architecture using uname -m and will download the appropriate payload depending on the architecture. Apple silicon is arm64, while systems using an Intel processor are x86_64. The corresponding URLs are:

  • arm64 Mach-O binary: hxxp[:]//45.131.215[.]56/a7a11f95?force=1
  • x86_64 Mach-O binary: hxxp[:]//45.131.215[.]56/4e04813226b1b93?force=1


Shown above: A later section of the downloaded shell script showing URLs for the follow-up malware.

A string of base64 text shown in the above image translates to a URL for the C2 server: hxxp[:]//95.163.153[.]80:8133/api/t

Post-Infection C2 Traffic

The post-infection C2 traffic on Thursday 2026-09-24 went a different IP address than I reported in my previous diary. But the URL patterns remained the same.


Shown above: Traffic from the infection filtered in Wireshark.

After retreiving the Mach-O binary, the infected macOS host reported to the C2 server that the download from the arm64 URL was good.


Shown above: The infected host reporting to the C2 server.

The infected host also reported to the server when the malware was exexuted (exec_start) and if it ran successfully (exec_ok). Then through more POST requests to the same /api/t URL, the infected host started reporting more information, and I started seeing the User-Agent string as Go-http-client/1.1.


Shown above: More traffic to the C2 server.

For C2-traffic, the biggest difference I've seen from AMOS Stealer is that this stealer uses websocket traffic.


Shown above: Request to switch protocol to websocket traffic.

In addition to websocket traffic, the infected host continued to send other HTTP POST requests. The next three images show an example of data exfiltration consisting of two HTTP requests in a single TCP stream.

These POST requests for data exfiltration used /api/credentials in the URL.


Shown above: Start of one of the HTTP POST requests for data exfiltration.


Shown above: End of one of the HTTP POST requests for data exfiltration.


Shown above: Follow-up HTTP POST request in the same TCP stream reporting "upload_session_ok."

Before exfiltrating various types of data, my infected macOS host asked to allow access to different folders and applications.

Permissions Requested By the Malware

The following images show the pop-ups I saw on my infected macOS host for access to various applications and folders.


Shown above: The first two access request pop-ups on my infected macOS host.


Shown above: The next four access request pop-ups on my infected macOS host.

The last pop-up requests were for my administrator password and my macOS Keychain password. The pop-up for the macOS Keychain password would not accept the administrator password, and I had not set up a separate password for it on the macOS host.


Shown above: The final pop-ups on my infected macOS host for passwords.

The pop-up messages were:

  • "bash" wants access to control the "Notes.app".
  • "Terminal.app" would like to access files in your Documents folder.
  • "Terminal.app" would like to access files in your Desktop folder.
  • "Terminal.app" would like to access files in your Downloads folder.
  • Allow "Terminal.app" to access your music, video activity, and media library in Apple Music?
  • Allow "Terminal.app" to access your photo library?
  • System Error pop-up requesting administrator password
  • macOS Keychain requires a separate password to protect your saved credentials.

Persistent Malware

A copy of the malware binary was made persistent through the following .plist file:

  • /Users/[username]/Library/LaunchAgents/com.apple.softwareupdated.plist

The above .plist file runs a copy of the Mach-O binary at:

  • /Users/[username]/Library/Caches/com.apple.softwareupdate/SoftwareUpdate

Notably, copies of the Mach-O binary were different from each other. They had slightly different file sizes and different SHA-256 hashes.

  • 33,492,336 bytes – Initial Mach-O arm64 binary from hxxp[:]//45.131.215[.]56/a7a11f95?force=1
  • 33,297,728 bytes – First saved binary at /Users/[username]/Library/Caches/com.apple.securityd/com.apple.periodic
  • 33,297,760 bytes – Persistent binary at /Users/[username]/Library/Caches/com.apple.softwareupdate/SoftwareUpdate

They all appear to be copies of the same binary but with some relatively slight differences from each other.

Indicators of Compromise

SHA-256 hash: c6da028e0a8a25a35efa28ba508a556d1b53d1e61113c0aaebf31a49a5668912
Description: Shell script loader from 45.131.215[.]56

SHA-256 hash: 457ed02b0a63ccf872e8459c91e2d1d6844a75414358849333f518cc538055b7
Description: x86_64 Mach-O binary from 45.131.215[.]56

SHA-256 hash: 5a2242b862ef52fe7a08af596198412a7676c948bcd64a25ce5d2e6d4b35c6fb
Description: arm64 Mach-O binary from 45.131.215[.]56

SHA-256 hash: 3e26e006210ed398f98c090e9f1c982e76b3b73f1ce3e04ee1bf8d45c56e1a89
Description: arm64 Mach-O binary first saved to disk com.apple.periodic

SHA-256 hash: 4a5952849232691849ed900609d7ff271ce296fe3cee4a81b58c28f2839fb5b6
Description: Persistent arm64 Mach-O binary SoftwareUpdate.bin

Location of files retrieved from the infected macOS host:

  • /Users/[username]/Library/LaunchAgents/com.apple.softwareupdated.plist
  • /Users/[username]/Library/Caches/com.apple.securityd/com.apple.periodic
  • /Users/[username]/Library/Caches/com.apple.softwareupdate/SoftwareUpdate

Macfinder ClickFix domain:

  • hollow-badger-moasfraum[.]life

Malware hosting URLs:

  • hxxp[:]//45.131.215[.]56/4e04813226b1b93?force=1
  • hxxp[:]//45.131.215[.]56/8031e818c7a46?force=1
  • hxxp[:]//45.131.215[.]56/a7a11f95?force=1

Post-infection C2 URLs:

  • hxxp[:]//95.163.153[.]80:8133/api/credentials
  • hxxp[:]//95.163.153[.]80:8133/api/shell/agent
  • hxxp[:]//95.163.153[.]80:8133/api/t

Final Words

As noted earlier, I don't think the malware is a variant of AMOS Stealer. However, I still don't know what to call it, and I could still be wrong. I suspect people more experienced with macOS malware can confirm what, exactly, this malware from the Macfinder ClickFix campaign is.

A packet capture (pcap) of the infection traffic and copies of the associated malware are available here.

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 enhanced custom event buses in Amazon EventBridge for enterprise-scale event-driven applications

Leave a comment
This post was originally published on this site

Organizations building event-driven applications on Amazon EventBridge typically start with a single custom event bus in one account. This works well when a single team owns the architecture. As adoption grows across the organization, though, things get complicated. AWS best practices recommend a multi-account structure, which means each team runs in its own account. To route events between them, teams create multiple event buses connected through cross-account rules or bus-to-bus configurations. This workaround reintroduces the operational complexity that serverless architectures are meant to eliminate. Platform teams lose visibility into who is subscribing to which events, cross-account and bus-to-bus routing charges compound quickly, and teams that need capabilities like event ordering are forced to build complex workarounds or adopt entirely different technologies.

Today, we are announcing an enhanced custom event bus in Amazon EventBridge, purpose-built for organizations scaling event-driven applications across teams and accounts. With the new enhanced custom event bus, you can deploy a single, centralized event bus shared across all AWS accounts in your organization, with ordering guarantees, a simplified Subscriber resource, and a new pricing model that delivers improved economics at scale and cost allocation for publishers and subscribers.

Let’s try it out

To get started with an enhanced custom event bus, I navigated to the EventBridge console in the AWS Management Console and opened the Create custom event bus page. I selected Custom event bus, the recommended option labeled New. The page also offered Custom event bus – classic, which continues to receive events and route them with rules and targets. Below the selection, EventBridge showed how the new bus works. One shared bus serves every team in the organization. Publishers send events, subscribers consume only what they need, and EventBridge handles ordering, retention, routing, and delivery.

The Create custom event bus page. Custom event bus is the recommended new option, with ordered delivery, filter patterns, event replay, and sharing across your AWS organization. Custom event bus – classic remains available for existing workloads.

Next, I configured resource sharing. I turned on Enable event bus sharing and selected Allow sharing only within your organization. I chose AWS account ID as the principal type. I could also share with an organization, an organizational unit, or an AWS Identity and Access Management (IAM) role or user. Sharing uses AWS Resource Access Manager (AWS RAM), so I did not have to set up cross-account permissions or bus-to-bus routing myself.

Resource sharing on the new custom event bus. I enabled sharing within my organization through AWS RAM and selected an AWS account as the principal, which is how teams publish and subscribe on the same bus without extra routing.

Organization-wide sharing

With the new enhanced custom event bus, you can create a single event bus and share it across all AWS accounts in your organization. Platform teams deploy one bus and establish it as the central event backbone, eliminating the need to configure cross-account permissions or bus-to-bus routing. Application teams across your organization can publish and subscribe to events on the same bus without waiting for infrastructure provisioning.

Publishers send events without needing to know which teams consume them, and subscribers create their own Subscriptions independently. Platform teams maintain visibility into all event flows and fine-grained control over who can publish and consume events. The new enhanced custom event bus has a default quota of 10,000 Subscribers per bus, and you can request a higher quota. That reduces the fragmentation that occurs when subscriber limits force you to split across multiple buses.

Event ordering

Event-driven architectures work best when consumers are designed around asynchronous patterns, where the order of events does not matter. There are a few cases where order does matter. In a logistics application, driver location updates must arrive in sequence. Out-of-sequence events cause routing algorithms to make decisions based on stale data.

The enhanced custom event bus supports both patterns on the same bus. Publishers can include an EventGroupId when sending events. EventBridge delivers events that share the same EventGroupId in sequence to Subscribers that chose ordered delivery. Other subscribers on that bus can receive the same events without ordering. You can keep events for each driver in the correct order without building complex workarounds, while the rest of your consumers stay fully asynchronous.

To support ordered processing, the enhanced custom event bus includes synchronous invocation for targets like AWS Lambda. Synchronous mode confirms successful processing before acknowledging the event, eliminating the common pattern of placing Amazon Simple Queue Service (Amazon SQS) between an event bus and Lambda to ensure reliability.

Subscriptions

The enhanced custom event bus introduces the Subscriber resource, which combines event filtering, target configuration, retry policies, and dead-letter destinations into a single, manageable unit. Today, achieving the same outcome with EventBridge requires configuring separate rules, targets, and retry settings across multiple resources. Subscribers simplify this by giving each consumer one resource that defines what events they want, where to deliver them, and how to handle failures.

Subscribers also include variable start time options, making it easier for teams to onboard new consumers or replay events to recover from application errors or hydrate new applications.

Event evaluation

Publishers can turn on content-based deduplication so EventBridge detects and drops retries of the same event from the payload itself. You do not have to generate and track a deduplication ID when a timeout or a partial failure sends the same event twice. EventBridge hashes the meaningful parts of the event and collapses matches that arrive within five minutes, which gives those retries exactly-once delivery semantics instead of EventBridge’s usual at-least-once model. If you already stamp your own idempotency token, keep using it. Content-based deduplication is for sources that cannot reliably identify the same event on a retry.

Subscribers can use JSONata expressions to reshape an event before it reaches a target, extracting fields, renaming them, or computing new values when a downstream API expects a different shape. If you already produce Apache Avro or Protocol Buffers events, EventBridge can deserialize those payloads to JSON, allowing subscribers fine grained filtering and routing on the full event payload without having to consume, deserialize, and match or discard on their own.

New pricing model

The enhanced custom event bus uses a new ingress and egress throughput pricing model. Publishers pay for events ingested, and subscribers pay for events delivered. This replaces the per-event model where cross-account and bus-to-bus routing charges compound in multi-bus architectures. For pricing details, visit the EventBridge pricing page.

Existing EventBridge custom event buses continue to work as they do today with no changes required. They now appear as Custom event bus – classic. The enhanced custom event bus is a new resource that you adopt at your own pace. In the console, it appears as Custom event bus.

Now available

The enhanced custom event bus is available today in the US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain), and Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo) Regions. You can create your first enhanced custom event bus through the AWS Management Console, AWS Command Line Interface (AWS CLI), or EventBridge APIs. To get started, visit the EventBridge documentation or try it out directly in the EventBridge console.

Security

One URL, Three Different Tricks, (Thu, Sep 24th)

Leave a comment
This post was originally published on this site

Yesterday, we received a phishing email with an interesting link. At first sight, it looks like garbage, but every piece of it has been carefully crafted to confuse basic security controls. Here is the defanged link:

hxxps://YKZjqa7A@gynd--[.]koncar-hr[.]com/handlers@isc.sans.edu

Let's break it down…

The first trick is the old "userinfo" field. According to RFC 3986[1], everything between the scheme and an "@" inside the authority is treated as credentials ("user:password@host"). Browsers silently ignore it, but it has two advantages for the attacker. The random string ("YKZjqa7A") makes every URL unique, which defeats exact-match blocklists and URL reputation lookups. It probably also acts as a tracking token per victim or campaign. As a side effect, the whole thing now looks like an email address to any tool that doesn't parse URLs strictly.

The second trick is the hostname itself: "gynd–.koncar-hr.com". Per the classic hostname rules (RFC 952/1123[2]), a label can't start or end with a hyphen. DNS doesn't care, and browsers happily resolve and visit it. However, strict validators, regex-based URL extractors, and some link-rewriting or sandboxing solutions may consider it invalid and simply skip it. A URL that is never extracted is never scanned. The random subdomain also suggests wildcard DNS, so each victim gets a brand-new hostname that no blocklist knows. The parent domain is a lookalike of the legitimate "koncar.hr" (a Croatian industrial group), with the ccTLD turned into a hyphenated ".com".

The last trick is the victim's email address, appended in the path. This is common with phishing kits: the page reads the path, pre-fills the login form with the victim's address, and sometimes adapts the branding to the email domain. There is another benefit, though. A poorly written parser that splits the string on the last "@" will conclude that the host is "isc.sans.edu", the recipient's own trusted domain! Per the WHATWG[3] URL standard, the authority ends at the first "/", so the browser correctly connects to the attacker's server.

The result is a single string that tells three different stories. A naive filter sees two email addresses or a link to your own domain. A strict validator sees an invalid hostname and drops it. The browser sees a perfectly valid URL and takes the victim straight to the phishing page. Attackers aren't exploiting a vulnerability here but the differences between parsers.

Tip: If you want to hunt for this kind of link, look for URLs with more than one "@", hostname labels starting or ending with a hyphen, and paths containing the recipient's own email address.

[1] https://www.rfc-editor.org/info/rfc3986/
[2] https://www.rfc-editor.org/info/rfc952/
[3] https://url.spec.whatwg.org

Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key

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

Security

Macfinger ClickFix campaign, (Tue, Sep 22nd)

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

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.

Interacting with the agent and viewing traces

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?”

Comparing two traces side by side

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.

Running evaluations on traces

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.

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

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

AWS

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

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)

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.

AWS

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

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