A threat actor has published hundreds of fake GitHub repositories impersonating legitimate software and security projects to distribute infostealer malware.

The campaign drew traffic from search results for security products, cryptocurrency services, financial tools, developer utilities, secure email providers, macOS utilities, and gaming software.

The malware collects data from more than 19 web browsers, steals info from 32 cryptocurrency wallets, and exfiltrates sensitive details from messaging and social media apps.

Cybersecurity company ArcticWolf identified the activity after finding that one of its products was impersonated in the campaign starting June 26.

In total, the researchers uncovered 292 fake repositories, each including a README file with a download link directing visitors to a malicious download page.

The landing pages feature wording and branding designed to inspire trust, such as a button named “Download Secure Content” and spoofed trust badges.

Analyzing the code for the delivery page, the researchers noticed that it relies on “a single templated HTML/JS artifact reused across all impersonated brands.”

” Its client-side script parses the URL path into two segments – path[0] as a user_code (the “rotating” path token, e.g., yyvxx9rswefr, which tracks the referring repository/redirector), and path[1] as the referrer domain (e.g., Arctic-Wolf[.]github.io),” Arctic Wolf says.

Visible branding is derived from a second segment when it is rendered, by replacing the hyphens with spaces and applying the proper title cases.

According to the researchers, the page delivers a large ZIP archive, whose name and payload is changed roughly every minute. Inside the archive is a trojanized libcurl.dll and a legitimate, signed WinGUP updater that gets a different name based on the impersonated product.

“When the user runs the executable, gup.exe side-loads libcurl.dll, which decodes and reflectively executes an embedded infostealer entirely in memory.”

The information stealer appears to be a variant of the BoryptGrab family, targeting the following data from infected systems:

• Passwords, cookies, payment information, and other data from 19 web browsers
• Data of 32 cryptocurrency wallet brands
• Telegram sessions, Discord tokens, and Steam session tokens
• Credentials for Meta’s Max messaging application
• Windows Credential Manager contents
• Files from Desktop and Documents whose names or extensions suggested passwords, recovery phrases, wallets, backups, etc.
• Screenshots, system details, and installed-software lists

The researchers note that this variant of BoryptGrab exhibits a previously undocumented capability to bypass Chrome’s App-Bound Encryption through direct code injection into the browser process.

The stolen data is compressed before being sent to a Russia-based command-and-control (C2) server.

Arctic Wolf reports that the malware does not establish persistence on the host and is instead designed to collect as much data as possible in a single execution.

Similarly, there’s no anti-analysis layer at all, and the temporary directory where the collected data is stored during exfiltration staging isn’t wiped, leaving forensic evidence behind. 

At the time of Arctic Wolf’s report, GitHub had removed a large portion of the malicious repositories, though the researchers report that several dozen GitHub Pages redirectors still remained active.

The researchers couldn’t attribute the campaign to a specific threat actor, though they assess that the operator is likely Russian-speaking and financially motivated.

Arctic Wolf concludes that the success of the campaign depends entirely on users trusting “free downloads” of premium software tools and recommends caution when interacting with unofficial GitHub pages.

The researchers shared a Yara rule for detecting this activity along with indicators of compromise (IoCs) associated with BoryptGrab.

Security teams log 54% of successful attacks and alert on just 14%. The rest move through your environment unseen.

The Picus whitepaper shows how breach and attack simulation tests your SIEM and EDR rules so threats stop slipping by detection.

Advertisement

Get the whitepaper

Over the years, phone-makers have shown off handsets that stretch, bend and fold. But inside a secret room at Samsung Display’s headquarters in South Korea — one that had never before been opened up to the press — I got a firsthand look at the company’s vision for the future of smartphones.

Along one wall sat a lineup of concept displays that could eventually make their way into future mobile devices. I wasn’t allowed to touch the prototypes, but they were mounted on machines that repeatedly bent, folded and rolled the displays, showing off their range of motion.

Watch this: I Went Inside Samsung’s Secret Display Lab and Saw Its Wildest Phone Concepts

03:16

Consumer tech shows such as CES and Mobile World Congress have become stages for companies to exhibit their most ambitious innovations — many of which never see the light of day. Still, they show how manufacturers are exploring ways to make our devices more intuitive and compelling. Samsung is one of the biggest players in the foldable phones market, having released the clamshell-style Flip, book-style Fold and even the phone-tablet hybrid Galaxy Z TriFold. The company’s expected to unveil the Galaxy Z 8 series next week at its Galaxy Unpacked event. 

During my visit to Samsung’s global headquarters in June, I got a rare behind-the-scenes look at how the company tests its latest mobile displays, along with an exclusive preview of what may be coming next. Samsung didn’t share specs for its concept displays, but here’s what I saw during my tour — and what it could mean for your future phone.

Advertisement

One concept, called the Flex S, opens and closes in a Z shape (not to be confused with the Galaxy Z TriFold, which forms a C shape and folds shut like a pamphlet). The Flex S opens up to a tablet-sized display, which could be ideal for watching movies. That’s what I appreciated about the TriFold, which I happened to review while recovering from strep throat. Lying in bed, I enjoyed having a larger screen for streaming that I could simply fold shut when I was finished.

See also: From Extreme Heat to Half a Million Folds: A Rare Look Inside Samsung’s Display Lab

Advertisement

Another prototype, called the Out Foldable, is like a reverse book-style foldable. Instead of placing the larger display on the inside, as Samsung does with the Galaxy Z Fold 7, the design puts both screens on the exterior and unfolds into a wider, mini-tablet-like layout, similar to some early foldables such as the 2019 Huawei Mate X. 

This is a configuration I’m a little more wary of for a couple of reasons. One, it might be hard to avoid scratching or cracking the wrap-around external display. And two, I’m not sure I really need a touchscreen display on the back of my phone. But I have to admit, it looks pretty cool nonetheless. 

Advertisement

The Flex Slidable does as the name suggests. It can roll out to a wider display, which could be helpful for gaming or watching videos. 

My first thought when I saw this concept was, “LG is rolling in its grave right now.” (Pun intended.) The company teased a rollable smartphone at CES 2021, but the product was canceled after the company shuttered its mobile division just a few months later. In 2023, Motorola also unveiled a rollable smartphone concept with a screen that extends upwards, and its parent company, Lenovo, showcased laptop concepts at this year’s CES that extend both horizontally and vertically. We’ll have to see if Samsung’s ideas make it out of the lab.

Advertisement

Lastly, Samsung combined elements from its other concepts to create what it’s dubbed the Flex Hybrid. This model can fold open and also expand with a rollable display. This makes for a more compact design while ensuring you don’t damage the screen. 

A foldable device with a rollable component provides extra screen real estate without adding as much bulk. One of the biggest drawbacks of the Galaxy Z TriFold is that it feels thick when its three display panels are folded shut. This approach could eliminate the need for an additional foldable panel, instead using a display that rolls out when you need more space and tucks away when you don’t.

Next to these concepts were a couple more that caught my eye — quite literally, in the case of one device that had a dazzling 5,000-nit peak brightness. For reference, the Galaxy S26 Ultra can hit a peak brightness of 2,600 nits. It was a lot to look at indoors, but that level of luminance could make it easier to peer at your screen in bright sunlight. 

And finally, I saw a prototype mobile display with bezels so thin they were almost invisible. To highlight just how narrow the 0.6mm borders around the screen were, Samsung placed the phone-sized concept device on top of a tablet display. The two screens combined to form a single image of colorful cathedral windows. From a distance, it was hard to tell there was even a phone in the middle of the tablet; the image appeared seamless, uninterrupted by a phone’s thick borders.

Advertisement

An expansive display stretching from one end of the phone to another can feel more immersive, but I also wonder how tricky it might be to hold the device without accidentally tapping something on the screen. 

As with all concepts, it’s not clear if or when Samsung will work these display technologies into its future mobile devices. But seeing these concepts offered a rare and fascinating glimpse into where smartphones could be headed.

In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.

The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.

I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.

Subnet And Conquer

The short version of ‘what is a subnet’ is to point at the subnet mask that we have been mostly mindlessly mashing into networking configuration dialogs along with the IPv4 address for many decades now. Usually this takes the form of 255.255.255.0, which is just the human-readable version of the actual bitmask. Here the loopback interface already tends to use 255.0.0.0 as its netmask, which is a detail that tends to be easy to gloss over as this is just one of those local OS things.

Putting netmasks in the crudest and simplest terms, they are a bitmask that is used to identify how an IPv4 pool of addresses is split up by defining which bits of the 32-bit IPv4 address identify a subnet. Normally we call the trailing part of an IPv4 address (the .123) the host identifier, with the preceding section the network identifier.

By masking part of this host ID and using it to create a subnet identifier, we can then use this for additional routing, just at the cost of a reduced number of possible host IDs within that subnet.

As an example, the common 255.255.255.0 mask identifies the first 24 bits (3 bytes) of the 32-bit (4-byte) IPv4 address, hence the mask being referred to as /24. With this mask, the remaining host ID bits allow for 256 hosts, of which two are not used for hosts: the first (e.g. 192.168.0.0) and last (e.g. 192.168.0.255) in the range. The last host ID in the range forms the broadcast address for that subnet.

This is why, for a /24 subnet, you can generally get away with just slapping a .255 on the end of an interface’s address, but also why for other subnet configurations it’s likely to explode violently.

To get briefly back to the loopback’s /8 style netmask, this means a single subnet with a maximum of 16,777,214 hosts, which ought to be sufficient for local system networking shenanigans. Its opposite extreme would be the /31 style netmask, which with just two potential host IDs is practically useless.

IPv6 subnetting is similar, but due to the much larger address pool and differences in the protocol this is a whole other kettle of fish that is as likely to send a network administrator’s heart racing in excitement as it is to make the average software developer run away screaming. This can be a fun topic for another day, perhaps.

This overview of IPv4 subnetting also skips over details like the different classes of IPv4 subnets beyond the Class A type here, but those are happily left to sysadmins and kin for now.

Sub-casting

In order to thus obtain the broadcast address for a given network interface you need to know two things: the IPv4 address and its associated netmask. From this you can then tell three things: the subnet ID, the broadcast address in that subnet, and the current host ID. Of these we only really care about the the second item.

Although you can obtain the broadcast address yourself by applying the netmask to the address, the OS’s APIs tend to happily give you the precomputed broadcast address. If that’s not your style or not an option, a manual procedure is to:

1. Determine the number of host ID bits using the netmask.
2. Set all bits to 1 in these bits to get the highest possible host ID.
3. Use this value along with the original masked (i.e. network ID) bits to obtain the broadcast address.

If we thus start with a 192.168.0.0/24 network, we end up with 192.168.0.255, while for a 192.168.0.0/26 network with just six bits available the maximum value is 64, ergo we get 192.168.0.63, since we start counting at 0.

With this we can now broadcast UDP packets on any interface without any (major) worries.

Local Broadcast Address

A small glitch in the whole above story is that there’s actually another broadcast address, one which is always the same for each interface and can be considered to make the whole preceding explanation completely irrelevant. This being the local, or limited, broadcast address, which is either the best thing since sliced bread or the worst sin ever committed in the history of IP networking, depending on whom you ask.

This cheat code takes the form of the address 255.255.255.255 and if you send a packet on a UDP socket to it, you’ll get happy UDP responses from any service that is listening on the specified port. This raises the point of why you’d not just use this broadcast address on all interface, rather than bother with all the earlier described nonsense.

The only major difference between this local broadcast address and the earlier described directed broadcast address is that the latter can also be used to target a foreign network, instead of just the local network. This makes it a very attractive option if you just want to query the local network with UDP broadcast packets.

As for why you’d not want to use a local broadcast address, I couldn’t really find any references or citations on why this would be the case. Both would appear to be perfectly valid approaches to broadcasting, each with its own pros and cons.

Bugs

One final topic was my mistaken hardcoding of a /24 style broadcast address in NyanSD. Here reader ziew helpfully pointed me towards the Poco::Net::NetworkInterface::broadcastAddress() function, which seemed perfect. Unfortunately Poco’s implementation at least on Windows 10 appears to be rather broken.

After getting only 0.0.0.0 as broadcast address from this function, I had a bit of a look at what was happening, including checking what I got as subnet mask both for the default index parameter and for the next index. Across two different Windows 10 installations and both GCC in MSYS2 as well as MSVC 2017/2022 with various versions of Poco the returned values were… interesting enough to file a bug report on the Poco issue tracker.

Clearly this isn’t going to be fixed just yet, but on the bright side the horrific atrocity that I committed by hardcoding a /24 broadcast address will still work on basically every home LAN out there that NymphCast is likely to be used on.

Maybe I could just switch to a local broadcast address and that’d be even better. Feel free to torch down this idea in the comments, just be sure to provide solid reasoning and cite your sources.

A Complex Topic

Writing out the above pretty much clarifies I think why past me got a bit overwhelmed when trying to ‘just do a UDP broadcast thing’. Even just scratching the surface of IPv4 subnets and not even venturing into IPv6 territory makes one already feel a bit antsy.

Certainly, one could totally argue that anything other than a /24 network is unlikely to be encountered outside of certain government and business networks with either very specific needs, very enthusiastic sysadmins, or both, but it’s always better to design software with such real-life scenarios in mind.

OpenAI’s entry into the world of consumer devices is expected to begin with the release of a portable smart speaker that lacks a screen, according to a Bloomberg report on Tuesday. The device is being positioned as “a new type of computer for the AI era,” Bloomberg’s Mark Gurman reported, adding that it would “serve as a humanlike AI companion that lives in the home.”

The device, which Gurman wrote is still in development, is expected to operate in much the same way today’s smart speakers do: answer questions, play media, operate smart-home appliances, as well as respond to messages and make use of capabilities offered by OpenAI’s ChatGPT.

But OpenAI’s device is expected to go a bit further into homes by offering a “personality” that would make a humanlike connection with users. It will include “mechanical elements that can move on their own, creating a sense that it is alive,” Bloomberg reported.

The product leak comes days after Apple sued OpenAI, accusing the company of stealing its trade secrets. Apple alleged it “uncovered a pattern of theft of Apple’s trade secrets by OpenAI employees who were formerly at Apple.” Apple also called the instances it uncovered “the tip of the iceberg.”

However, OpenAI feels its new product “veers significantly” from any Apple device currently on the market and that it is “unlikely” its new device violates any Apple trade secrets, according to anonymous sources described as knowledgeable of OpenAI’s plans.

There’s been much speculation lately about OpenAI’s hardware ambitions. The company has been linked to a possible release of AI earbuds later this year or early 2027 and is also said to be working on a smartphone in partnership with component-makers MediaTek, Qualcomm and Luxshare. 

OpenAI’s hardware ambitions have included a high-profile partnership with former Apple designer Jony Ive. One recent rumor was that the devices could include one worn in the ear, but that OpenAI could have as many as five different devices ready by the end of 2028. 

OpenAI didn’t immediately respond to a request for comment. 

(Disclosure: Ziff Davis, CNET’s parent company, in April 2025 filed a lawsuit against OpenAI, alleging it infringed Ziff Davis copyrights in training and operating its AI systems.)

Strands is the NYT’s latest word game after the likes of Wordle, Spelling Bee and Connections – and it’s great fun. It can be difficult, though, so read on for my Strands hints.

Want more word-based fun? Then check out my NYT Connections today and Quordle today pages for hints and answers for those games, and Marc’s Wordle today page for the original viral word game.

A security researcher published a wire-level analysis on July 12 proving that xAI’s Grok Build coding CLI was packaging developers’ entire tracked repositories, including full Git history, committed secrets, and API keys, and sending them to a Google Cloud Storage bucket. The upload volume was roughly 27,800 times greater than the data the coding task actually required, according to the analysis.

The researcher, publishing as cereblab, tested version 0.2.93 of Grok Build, intercepted the upload, cloned the git bundle from the captured request, and recovered a file the AI agent had been explicitly told not to open. xAI had marketed the tool with claims that “nothing from your codebase transmitted to xAI servers during a session.” The wire data directly contradicts this.

The privacy toggle that was supposed to prevent data transmission did nothing, according to multiple reports. Grok has a history of privacy issues, including training on X user data without consent in what regulators called a “very likely” breach of EU law. A quarter of European firms have banned Grok entirely in favour of alternatives with better security controls.

Elon Musk confirmed the uploads and said SpaceXAI would delete all prior Grok Build user data. The company documented a “zero data retention” policy and added a /privacy endpoint. A same-client retest observed a server-side flag disabling the uploads. However, no independent audit has confirmed the deletion. Grok Build launched alongside Grok 4.5 as xAI’s answer to Claude Code and Cursor, making the privacy breach particularly damaging for a product positioned to win enterprise developer trust.

• Kokuyo Energy Line replaces discrete sockets with one continuous slot that takes up to five two-prong plugs anywhere along its length
• It won a 2025 Good Design Award thanks to its accessibility, style, and attention to detail
• The Kokuyo Energy Line also offers an inclusive design that allows users with upper limb disabilities to easily use the product with just 1 hand

Kokuyo is a well-known Japanese furniture giant that focuses on both functionality and aesthetics across its furniture and interior design lines.

It regularly collects Good Design Awards even as it runs a public “live office” where users can test out hardware in a workplace setting, in addition to HOWS DESIGN, an inclusive-design program that has birthed multiple successes.