 The FBI cybersecurity alert, I-060525-PSA, could not have been clearer: ongoing attacks are targeting everything from streaming devices, digital picture frames, third-party aftermarket automobile infotainment systems and other assorted home smart devices. The devices, all low-cost and uncertified, mostly originating in China, allow attackers to access your home network and beyond by, the FBI warned, “configuring the product with malicious software prior to the user’s purchase.” It has also been noted, however, that mandatory “software updates” during the installation process can also install a malicious backdoor. Point Wild’s Threat Intelligence Lat61 Team reverse-engineered the BadBox 2 infection chain and, as a result, uncovered new indicators of compromise that have been shared with global Computer Emergency Response Teams, as well as law enforcement. “This Android-based malware is pre-installed in the firmware of low-cost IoT devices, smart TVs, TV boxes, tablets, before they even leave the factory,” Kiran Gaikwad from the LAT61 team said, “It silently turns them into residential proxy nodes for criminal operations like click fraud, credential stuffing, and covert command and control (C2) routing.” Google, meanwhile, confirmed in a July 17 statement that it had “filed a lawsuit in New York federal court against the botnet’s perpetrators.” Google also said that it has “updated Google Play Protect, Android’s built-in malware and unwanted software protection, to automatically block BadBox-associated apps.” Human Security, whose Satori Threat Intelligence and Research Team originally both disclosed and disrupted the BadBox 2.0 threat campaign, said at the time that researchers believed “several threat actor groups participated in BadBox 2.0, each contributing to parts of the underlying infrastructure or the fraud modules that monetize the infected devices, including programmatic ad fraud, click fraud, proxyjacking, and creating and operating a botnet across 222 countries and territories.” If nothing else, that provides some context to the scale of this campaign. Now, Stu Solomon, the Human Security CEO, has issued the following statement: “We applaud Google’s decisive action against the cybercriminals behind the BadBox 2.0 botnet our team uncovered. This takedown marks a significant step forward in the ongoing battle to secure the internet from sophisticated fraud operations that hijack devices, steal money, and exploit consumers without their knowledge. Human’s mission is to protect the integrity of the digital ecosystem by disrupting cybercrime at scale, and this effort exemplifies the power of collective defense. We’re proud to have been deeply involved in this operation, working in close partnership with Google, TrendMicro, and the Shadowserver Foundation. Their collaboration has been invaluable in helping us expose and dismantle this threat.” A new report, initiated by Jeff Golden, lead software engineer at GreyNoise and supported by the GreyNoise research team, has confirmed another global botnet operation to worry about. The investigation was prompted by a small region on the intelligence map that was lighting up with activity that all showed the same fingerprint: a Telnet brute-forcer, generic default password attempts against an internet of things device, and a hardcoded Telnet attempt for good measure. An AI-powered analysis by the GreyNoise research team quickly identified that the systems involved were all VoIP-enabled devices. “Using GreyNoise tags, behavioral similarity, and Telnet traffic patterns,” the GreyNoise report stated, “we identified about 500 IPs globally exhibiting similar traits.” The security researchers suggested that, as VoIP devices frequently operate on old Linux-based firmware, and often have Telnet exposed by default, they are rife for vulnerability-based attack surface threats. These VoIP devices can, the report said, often be internet-facing, lightly monitored (if at all) and infrequently patched. “While we did not confirm exploitation of that CVE in this case,” the researchers explained, “the activity reinforces a broader point: Vulnerabilities remain part of the attack surface long after disclosure.” And all of this matters, according to GreyNoise, because VoIP systems are so often overlooked during security monitoring operations. Not just by users, but by small utilities and internet service providers who may “unknowingly contribute infrastructure to global botnets.” The botnet in question, likely Mirai-related, is nearly always opportunistic and will be exploited wherever it can. Which is why defenders should be sure to audit Telnet exposure, especially on VoIP-enabled systems, and “rotate or disable default credentials on edge and SOHO devices,” the GreyNoise research team recommended. For more please visit OUR FORUM.  Once upon a time, signing into sites and apps was simple. You remember those days, right? (They really weren’t that long ago, though by tech standards, it’s been roughly seven centuries.) All you’d do is remember a single username and password — or maybe put it on a Post-it and stick it to the bottom of your 11″ oatmeal-gray 7,000-lb. monitor monster, if you were really feeling fancy — and that’s it: You’d be ready to rush into whatever site or service you wanted, whenever the need arose. Now, it’s a whole other story. If you’re following best practices, you’ve got unique, complex alphanumerical passwords for every single site and service you visit — managed by a password manager and supplemented by two-factor authentication. And if that isn’t enough, you’re increasingly being prompted to drop all of those elements and instead rely on a newer and even more mystifying method of authentication called a passkey. Whether you’re a gadget-loving technophile or a perpetually befuddled technophobe — and whether you’re an individual tech user or part of a broader corporate organization — the one consistent reality about passkeys is that they’re confusing as all get-out. Their aim may be to simplify security around sign-ins, but in actuality, they create all sorts of uncertainty and unanswered questions. Let’s start at the beginning: Passkeys are a relatively recent security feature that let you log in to an account simply by authenticating on a device with your fingerprint or face scan — or, in some cases, another screen lock mechanism (e.g., the PIN or passcode you put into your device when first firing it up). In a sense, it’s kind of like two-factor authentication — only instead of typing in a traditional password and then verifying it’s you as a second step, you’re basically just jumping right to that second step with the knowledge that such action shows you’ve already unlocked an approved device and demonstrated your identity. The idea is that passwords are inherently vulnerable, since they’re text-based codes that you type in or store somewhere and thus that someone else could potentially access or figure out (or find in one of the endless series of breaches we hear about these days). With a passkey, that risky variable is eliminated. Instead, you’re signing in solely based on the fact that you’ve already unlocked your phone or computer — ideally using some manner of biometric authentication but at the very least using a PIN or passcode there — and thus have already proven who you are. And you set up a different passkey for each site or service, eliminating the possibility of reused credentials. Plus, you personally have that device in front of you, which means a hacker couldn’t crack the code and pretend to be you without physically taking your device and being able to get past its lock screen. On a technical level, the bits and bytes that make up a passkey are encrypted with public key cryptography — a fancy way of saying they rely on a pair of keys, one that’s public and one that’s stored privately on your local device — which makes them exceptionally difficult to crack or plunder. That’s in large part because of the way the private key piece of the puzzle works: In short, the site you’re signing into never sees your private key and only receives confirmation that it’s present and valid. The key itself remains on your device, with encryption keeping it unreadable until the moment you authenticate. The actual passkey data is never transferred during the login, and there’s no real mechanism to even copy and paste it anywhere, like you would with a password, so the potential for a hacker to exploit it is pretty darn slim. The one extra wrinkle is that for most people and purposes, the underlying (and encrypted) passkey data is synced to a service that’s connected to a secure account you own and thus can use to sign back in and restore the passkey on a different device. That’s the case with the Google Password Manager system associated with Android, with the iCloud Keychain system associated with iOS, and with most third-party password managers such as 1Password and Bitwarden, too. For more visit OUR FORUM.  Microsoft has confirmed a new known issue causing delivery delays for June 2025 Windows security updates due to an incorrect metadata timestamp. As Redmond explains in recent advisory updates, this bug affects Windows 10 and Windows 11 systems in environments with quality update deferral policies that enable admins to delay update installation on managed devices. While update deployment delays are an expected result when using such policies, the wrong timestamp for the June security updates will postpone them beyond the period specified by administrators, potentially exposing unpatched systems to attacks. "Some devices in environments where IT admins use quality update (QU) deferral policies might experience delays in receiving the June 2025 Windows security update," Microsoft explains. "Although the update was released on June 10, 2025, its update metadata timestamp reflects a date of June 20, 2025. This discrepancy might cause devices with configured deferral periods to receive the update later than expected." While still investigating this known issue, Microsoft has provided Windows admins with several temporary workarounds to accelerate deployment for the June 2025 updates until a fix is available. To achieve this, Redmond recommends creating an expedited deployment policy to bypass deferral settings and ensure that the updates are delivered immediately in organizations using Windows Autopatch. As an alternative, admins can modify deferral configurations or deployment rings to minimize the delay for impacted devices. "This delay issue affects only the timing of update availability for organizations using QU deferral policies and doesn't impact the quality or applicability of the update," Microsoft added. "We will not change the metadata value from the current June 20, 2025, value. This workaround is the final resolution we will provide for this issue." Earlier this month, Microsoft rolled out a configuration update (KB5062324) to address a known issue that caused update failures after the scan for Windows updates stopped responding on some Windows 11 systems. In May, Redmond fixed another bug blocking Windows 11 24H2 feature updates from being delivered via Windows Server Update Services (WSUS) after installing the April 2025 security updates. One month earlier, it addressed what it described as a "latent code issue" that was causing some PCs to be upgraded to Windows 11 overnight despite Intune policies designed to block Windows 11 upgrades. In May, the company also revealed that it aims to update all software on your PC via a new update orchestration platform built on top of the existing Windows Update infrastructure, a platform that aims to unify the updating system for all apps, drivers, and system components across all Windows systems. Learn more by visiting OUR FORUM. |
Latest Articles
|