By continuing to use the site or forum, you agree to the use of cookies, find out more by reading our GDPR policy

This story, originally published on August 7, has been updated with additional information following a demonstration of the shared service principal exploit at the Black Hat hacking conference in Las Vegas, which, in turn, follows a Microsoft Exchange vulnerability directive issued by CISA. Details of a newly announced protection that adds to the Microsoft Defender security arsenal have also been added to the article. Hot on the heels of an official security advisory from America’s Cyber Defense Agency warning of camera hack attacks, the U.S. Cybersecurity and Infrastructure Security Agency has issued another alert. This time, it impacts users of Microsoft Exchange Server and, without immediate remediation, could enable an attacker to escalate privileges and “impact the identity integrity of an organization’s Exchange Online service.” But it’s not all bad news on the Microsoft security front; the technology giant has confirmed new AI-powered protections to autonomously reverse engineer and classify malware, importantly, without any prior context requirement. Here’s what you need to know. There have been a number of security warnings impacting Microsoft users of late that may have caught your attention: the Windows JPEG hackers and, of course, the by now infamous SharePoint Server attacks to name but two. The very latest, however, comes with the added weight of a CISA alert attached. “CISA is aware of the newly disclosed high-severity vulnerability, CVE-2025-53786,” the August 6 advisory warned, “that allows a cyber threat actor with administrative access to an on-premise Microsoft Exchange server to escalate privileges by exploiting vulnerable hybrid-joined configurations.” Microsoft, meanwhile, has said that “starting in August 2025, we will begin temporarily blocking Exchange Web Services traffic using the Exchange Online shared service principal,” as part of a “phased strategy to speed up customer adoption of the dedicated Exchange hybrid app and making our customers’ environments more secure.” Although CISA confirmed that there has not been any observed active exploitation of CVE-2025-53786, it strongly urged organizations to follow the Microsoft guidance on this issue. CVE-2025-53786 is officially listed as a Microsoft Exchange Server Hybrid Deployment elevation of privilege vulnerability that follows an accompanying non-security hot fix when the hybrid deployments were announced on April 18. “Following further investigation,” the official Common Vulnerabilities and Exposures database entry reads, “Microsoft identified specific security implications tied to the guidance and configuration steps outlined in the April announcement.” CISA added that it “highly recommends entities disconnect public-facing versions of Exchange Server or SharePoint Server that have reached their end-of-life (EOL) or end-of-service from the internet.” A researcher from Outsider Security, Dirk-Jan Mollema, has now demonstrated how the shared service principal behind the latest CISA advisory and directive can be exploited. The demonstration, during a presentation at the Black Hat hacking conference in Las Vegas, went ahead after Microsoft was informed of its contents three weeks prior, Mollema told reporters from the Bleeping Computer cybersecurity site. As a result, the CVE-2025-53786 classification was made, and Microsoft issued the aforementioned mitigation guidance. "The report describing the possibilities for attackers was sent as a heads up to the Microsoft Security Response Center three weeks before Black Hat,” Mollema confirmed, adding that “aside from this guidance Microsoft also mitigated an attack path that could lead to full tenant compromise (Global Admin) from on-prem Exchange." The shared service principle being that, at least in such hybrid configurations as relevant to the Microsoft Exchange warning, both Exchange Online and on-premises servers share a relationship of trust that allows them to, supposedly securely, authenticate with each other. As the Black demonstration showed, provided the attacker has admin privileges for the on-premise Exchange server, so-called trusted tokens can be forged, and API calls manipulated, so as to appear perfectly legitimate as far as the cloud side of the authentication equation is concerned. Stay informed by visiting OUR FOTUM often.

 

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.