Nginx UI flaw CVE-2026-27944 lets attackers download and decrypt server backups without authentication, exposing sensitive data on public management interfaces. A critical vulnerability in Nginx UI, tracked as CVE-2026-27944 (CVSS score of 9.8), allows attackers to download and decrypt full server backups without authentication. The flaw poses a serious risk to organizations exposing the management interface, potentially revealing sensitive configuration data, credentials, and encryption keys. “The /api/backup endpoint is accessible without authentication and discloses the encryption keys required to decrypt the backup in the X-Backup-Security response header.” reads the advisory. “This allows an unauthenticated attacker to download a full system backup containing sensitive data (user credentials, session tokens, SSL private keys, Nginx configurations) and decrypt it immediately.” The vulnerability stems from two major flaws: the /api/backup endpoint lacks authentication, allowing anyone to request a full system backup, and the server exposes the AES-256 encryption key and IV in an HTTP response header. As a result, attackers can download and immediately decrypt backups containing credentials, configuration files, databases, and SSL private keys, exposing the entire Nginx environment. Nginx UI is a web-based management dashboard designed to simplify the administration of Nginx servers. Instead of configuring Nginx through command-line files, administrators can use a graphical interface to manage servers, monitor performance, and update configurations. The advisory includes a Proof of Concept (PoC) exploit code for this vulnerability. The exploitation of the vulnerability could have serious consequences because a full Nginx UI backup contains large amounts of sensitive operational data. Once decrypted, attackers may obtain admin credentials and session tokens, allowing them to take control of the management interface, alter configurations, redirect traffic, or deploy malicious rules. The archive may also include private SSL keys, enabling website impersonation or man-in-the-middle attacks. In addition, database credentials and configuration files could expose application secrets and user data. Nginx configuration files may also reveal internal infrastructure details such as reverse proxy routes, upstream services, and virtual hosts, giving attackers a clear map of the organization’s web environment. The vulnerability highlights a key security principle: management interfaces should never be exposed to the public internet. Organizations should restrict access through private networks, VPNs, or secure tunnels. Additional protections such as IP allowlisting, multi-factor authentication, and network segmentation can further reduce risk. Regular security reviews of APIs and admin endpoints are also essential, as small design flaws can create major security gaps. Because Nginx is widely used in modern infrastructure, vulnerabilities in management tools like Nginx UI can quickly become serious threats. Keeping these tools secure and regularly updated is essential to protect servers and the sensitive data they handle. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CVE-2026-27944)

I’m about 1 year into my cybersecurity career and would appreciate some perspective from people further along. Current situation Role: Junior Security Analyst in an ITDR (Identity Threat Detection & Response) company Experience: ~1 year Daily work: analyzing logs from Okta, Entra ID, Active Directory, and sometimes network telemetry PAM bypass detection and identity-based threat detections So most of my exposure so far is around identity telemetry and authentication-related attacks. I’m trying to figure out how to position myself for the next 2–3 years. My concern If I go deep into identity security, I want to make sure I don’t end up in IAM operations (provisioning, access requests, SSO onboarding, etc.). I want to stay on the security engineering side detection, attack analysis, privilege escalation detection, etc. What I’m considering Option A specialize in Identity Security / ITDR / Privileged Access detection Option B move toward broader detection engineering (endpoint, network, cloud, identity combined) Is specializing in identity security / ITDR a good long-term path? what kinda companies should i target submitted by /u/Termed_soda [link] [comments]

Staring at traffic logs that make no sense under any framework I've used for the past decade, because what's hitting our endpoints now isn't bots in the way we used to think about bots, it's AI agents, some of which we'd actually want to let through like shopping assistants or legitimate crawlers, and some of which are clearly probing checkout flows and scraping pricing data in patterns organic enough to walk straight past our existing filters. The bot-or-not question has completely collapsed as a useful frame because the real problem is intent and trust, and nothing in our current stack gives us that granularity we’re looking for. So here we are looking for tooling that does actual intent-based classification with real session-level visibility. submitted by /u/Common_Contract4678 [link] [comments]

We've periodically been running our scanner on OSS repos as a fun experiment. Here's one of the most interesting issues it found. Auth bypasses defy most patterns, and require reasoning about the actual underlying logic of the application. You can see how the scanner found it here: it inferred an invariant and then noticed this wasn't enforced on certain APIs. Then, it stood up the actual service, wrote a PoC using the unauthenticated endpoints, and verified it could break something. This netted us $750! It's not too much, but validation is always nice 🙂 submitted by /u/securely-vibe [link] [comments]

A phishing page disguised as a Google Meet update notice is silently handing victims’ Windows computers to an attacker-controlled management server. No password is stolen, no files are downloaded, and there are no obvious red flags. It just takes a single click on a convincing Google Meet fake update prompt to enroll your Windows PC into an attacker-controlled device management system. “To keep using Meet, install the latest version” The social engineering is almost embarrassingly simple: an app update notice in the right brand colors. The page impersonates Google Meet well enough to pass a casual glance. But neither the Update now button nor the Learn more link below it goes anywhere near Google. Both trigger a Windows deep link using the ms-device-enrollment: URI scheme. That’s a handler built into Windows so IT administrators can send staff a one-click device enrollment link. The attacker has simply pointed it at their own server instead. What “enrollment” actually means for your machine The moment a visitor clicks, Windows bypasses the browser and opens its native Set up a work or school account dialog. That’s the same prompt that appears when a corporate IT team provisions a new laptop. The URI arrives pre-populated: The username field reads collinsmckleen@sunlife-finance.com (a domain impersonating Sun Life Financial), and the server field already points to the attacker’s endpoint at tnrmuv-api.esper[.]cloud. The attacker isn’t trying to perfectly impersonate the victim’s identity. The goal is simply to get the user to click through a trusted Windows enrollment workflow, which grants device control regardless of whose name appears in the form. Campaigns like this rarely expect everyone to fall for them. Even if most people stop, a small percentage continuing is enough for the attack to succeed. A victim who clicks Next and proceeds through the wizard will hand their machine to an MDM (mobile device management) server they have never heard of. MDM (Mobile Device Management) is the technology companies use to remotely administer employee devices. Once a machine is enrolled, the MDM administrator can silently install or remove software, enforce or change system settings, read the file system, lock the screen, and wipe the device entirely, all without the user’s knowledge. There is no ongoing malware process to detect, because the operating system itself is doing the work on the attacker’s behalf. The attacker’s server is hosted on Esper, a legitimate commercial MDM platform used by real enterprises. Decoding the Base64 string embedded in the server URL reveals two pre-configured Esper objects: a blueprint ID (7efe89a9-cfd8-42c6-a4dc-a63b5d20f813) and a group ID (4c0bb405-62d7-47ce-9426-3c5042c62500). These represent the management profile that will be applied to any enrolled device. The ms-device-enrollment: handler works exactly as Microsoft designed it, and Esper works exactly as Esper designed it. The attacker has simply pointed both at someone who never consented. No malware, no credential theft. That’s the problem. There is no malicious executable here, and no phished Microsoft login. The ms-device-enrollment: handler is a documented, legitimate Windows feature that the attacker has simply redirected. Because the enrollment dialog is a real Windows system prompt rather than a spoofed web page, it bypasses browser security warnings and email scanners looking for credential-harvesting pages. The command infrastructure runs on a reputable SaaS platform, so domain-reputation blocking is unlikely to help. Most conventional security tools have no category for “legitimate OS feature pointed at hostile infrastructure.” The broader trend here is one the security industry has been watching with growing concern: attackers abandoning malware payloads in favor of abusing legitimate operating system features and cloud platforms. What to do if you think you’ve been affected Because the attack relies on legitimate system features rather than malware, the most important step is checking whether your device was enrolled. Check whether your device was enrolled: Open Settings > Accounts > Access work or school. If you see an entry you don’t recognize, especially one referencing sunlife-finance[.]com or esper[.]cloud, click it and select Disconnect. If you clicked “Update now” on updatemeetmicro[.]online and completed the enrollment wizard, treat your device as potentially compromised. Run an up-to-date, real-time anti-malware solution to check for any secondary payloads the MDM server may have pushed after enrollment. If you are an IT administrator, consider whether your organization needs a policy blocking unapproved MDM enrollment. Microsoft Intune and similar tools can restrict which MDM servers Windows devices are allowed to join. We don’t just report on threats—we remove them Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

A campaign by Iran-linked group Dust Specter is targeting Iraqi officials with phishing emails delivering new malware families. Zscaler ThreatLabz researchers linked the Iran-nexus group Dust Specter to a campaign targeting Iraqi government officials. Threat actors impersonated the country’s Ministry of Foreign Affairs in phishing messages that delivered previously unseen malware, including SPLITDROP, TWINTASK, TWINTALK, and GHOSTFORM, through multiple infection chains. “In January 2026, Zscaler ThreatLabz observed activity by a suspected Iran-nexus threat actor targeting government officials in Iraq.” reads the report published by Zscaler. “Due to significant overlap in tools, techniques, and procedures (TTPs), as well as victimology, between this campaign and activity associated with Iran-nexus APT groups, ThreatLabz assesses with medium-to-high confidence that an Iran-nexus threat actor conducted this operation. ThreatLabz tracks this group internally as Dust Specter. “ The researchers analyzed two attack chains used in the Dust Specter campaign targeting Iraqi officials. Attack Chain 1 begins with a password-protected archive containing a dropper named SPLITDROP, disguised as a WinRAR application. Once executed, it decrypts and deploys two modules: TWINTASK, a worker component that executes PowerShell commands from a local file, and TWINTALK, a command-and-control (C2) orchestrator. “Attack Chain 1 is delivered in a password-protected RAR archive named mofa-Network-code.rar. The password for this archive is: 92,110-135_118-128. A 32-bit .NET binary, disguised as a WinRAR application, is present inside this archive and starts the attack chain on the endpoint.” continues the report. “This binary functions as a dropper and ThreatLabz named it SPLITDROP because it drops two modules that we named TWINTASK and TWINTALK. “ The malware establishes persistence through registry keys and uses DLL sideloading with legitimate software such as VLC and WingetUI. TWINTALK communicates with the C2 server using randomized delays, custom URI paths, and JWT tokens to evade detection. Commands allow attackers to execute scripts, upload files, or download additional payloads. Attack Chain 2, called GHOSTFORM, consolidates the same functionality into a single binary that executes commands directly in memory, reducing filesystem traces. It also opens a fake Google Form posing as a survey from Iraq’s Ministry of Foreign Affairs to lure victims. The malware employs stealth techniques such as invisible Windows forms for delayed execution and mutex checks to avoid multiple instances. ThreatLabz found indicators that generative AI may have been used to develop the TWINTALK and GHOSTFORM malware. During code analysis, researchers identified unusual elements such as emojis and Unicode text embedded in functions. They also observed placeholder values—like the seed 0xABCDEF—often associated with AI-generated code, suggesting automated tools may have assisted in malware development. The campaign also used a ClickFix lure disguised as a Cisco Webex meeting page to trick victims into running malicious PowerShell commands that download and schedule malware execution. “ThreatLabz found that the TWINTALK C2 domain, meetingapp[.]site, was also used by Dust Specter in July 2025 to host a web page disguised as a Cisco Webex meeting invitation.” states the report. “The web page included a link to download the legitimate Cisco Webex software and prompted the victim to choose the “Webex for Government” option. The web page also lures the victim into following the instructions shown in the figure below to retrieve the meeting ID.” ThreatLabz attributes the activity to Dust Specter, an Iran-linked threat actor, citing targeting patterns, malware design, and tactics consistent with previous Iranian cyber-espionage operations. “This campaign, attributed with medium-to-high confidence to Dust Specter, likely targeted government officials using convincing social engineering lures impersonating Iraq’s Ministry of Foreign Affairs. ThreatLabz identified previously undocumented lightweight custom .NET-based droppers and backdoors used in this operation.” concludes the report. “The activity also reflects broader trends, including ClickFix-style techniques and the growing use of generative AI for malware development.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Iran)

A convincing fake version of the popular Mac utility CleanMyMac is tricking users into installing malware. The site instructs visitors to paste a command into Terminal. If they do, it installs SHub Stealer, macOS malware designed to steal sensitive data including saved passwords, browser data, Apple Keychain contents, cryptocurrency wallets, and Telegram sessions. It can even modify wallet apps such as Exodus, Atomic Wallet, Ledger Wallet, and Ledger Live so attackers can later steal the wallet’s recovery phrase. The site impersonates the CleanMyMac website, but is unconnected to the legitimate software or the developers, MacPaw. Remember: Legitimate apps almost never require you to paste commands into Terminal to install them. If a website tells you to do this, treat it as a major red flag and do not proceed. When in doubt, download software only from the developer’s official website or the App Store. Read the deep-dive to see what we discovered. “Open Terminal and paste the following command” The attack begins at cleanmymacos[.]org, a website designed to look like the real CleanMyMac product page. Visitors are shown what appears to be an advanced installation option of the kind a power user might expect. The page instructs them to open Terminal, paste a command, and press Return. There’s no download prompt, disk image, or security dialog. That command performs three actions in quick succession: First, it prints a reassuring line: macOS-CleanMyMac-App: https://macpaw.com/cleanmymac/us/app to make the Terminal output look legitimate. Next, it decodes a base64-encoded link that hides the real destination. Finally, it downloads a shell script from the attacker’s server and pipes it directly into zsh for immediate execution. From the user’s perspective, nothing unusual happens. This technique, known as ClickFix, has become a common delivery method for Mac infostealers. Instead of exploiting a vulnerability, it tricks the user into running the malware themselves. Because the command is executed voluntarily, protections such as Gatekeeper, notarization checks, and XProtect offer little protection once the user pastes the command and presses Return. Geofencing: Not everyone gets the payload The first script that arrives on the victim’s Mac is a loader, which is a small program that checks the system before continuing the attack. One of its first checks looks at the macOS keyboard settings to see whether a Russian-language keyboard is installed. If it finds one, the malware sends a cis_blocked event to the attacker’s server and exits without doing anything else. This is a form of geofencing. Malware linked to Russian-speaking cybercriminal groups often avoids infecting machines that appear to belong to users in CIS countries (the Commonwealth of Independent States, which includes Russia and several neighboring nations). By avoiding systems that appear to belong to Russian users, the attackers reduce the risk of attracting attention from local law enforcement. The behavior does not prove where SHub was developed, but it follows a pattern long observed in that ecosystem, where malware is configured not to infect systems in the operators’ own region. If the system passes this check, the loader sends a profile of the machine to the command-and-control server at res2erch-sl0ut[.]com. The report includes the device’s external IP address, hostname, macOS version, and keyboard locale. Each report is tagged with a unique build hash, a 32-character identifier that acts as a tracking ID. The same identifier appears in later communications with the server, allowing the operators to link activity to a specific victim or campaign. “System Preferences needs your password to continue” Comparing payloads served with and without a build hash reveals another campaign-level field in the malware builder: BUILD_NAME. In the sample tied to a build hash, the value is set to PAds; in the version without a hash, the field is empty. The value is embedded in the malware’s heartbeat script and sent to the command-and-control (C2) server during every beacon check-in alongside the bot ID and build ID. What PAds stands for cannot be confirmed from the payload alone, but its structure matches the kind of traffic-source tag commonly used in pay-per-install or advertising campaigns to track where infections originate. If that interpretation is correct, it suggests victims may be reaching the fake CleanMyMac site through paid placements rather than organic search or direct links. Once the loader confirms a viable target, it downloads and executes the main payload: an AppleScript hosted at res2erch-sl0ut[.]com/debug/payload.applescript. AppleScript is Apple’s built-in automation language, which allows the malware to interact with macOS using legitimate system features. Its first action is to close the Terminal window that launched it, removing the most obvious sign that anything happened. Next comes the password harvest. The script displays a dialog box that closely mimics a legitimate macOS system prompt. The title reads “System Preferences”, the window shows Apple’s padlock icon, and the message says: The awkward wording—“for continue” instead of “to continue”—is one clue the prompt is fake, though many users under pressure might not notice it. “Required Application Helper. Please enter password for continue.” If the user enters their password, the malware immediately checks whether it is correct using the macOS command-line tool dscl. If the password is wrong, it is logged and the prompt appears again. The script will repeat the prompt up to ten times until a valid password is entered or the attempts run out. That password is valuable because it unlocks the macOS Keychain, Apple’s encrypted storage system for saved passwords, Wi-Fi credentials, app tokens, and private keys. Without the login password, the Keychain database is just encrypted data. With it, the contents can be decrypted and read. A systematic sweep of everything worth stealing With the password in hand, SHub begins a systematic sweep of the machine. All collected data is staged in a randomly named temporary folder—something like /tmp/shub_4823917/—before being packaged and sent to the attackers. The browser targeting is extensive. SHub searches 14 Chromium-based browsers (Chrome, Brave, Edge, Opera, OperaGX, Vivaldi, Arc, Sidekick, Orion, Coccoc, Chrome Canary, Chrome Dev, Chrome Beta, and Chromium), stealing saved passwords, cookies, and autofill data from every profile it finds. Firefox receives the same treatment for stored credentials. The malware also scans installed browser extensions, looking for 102 known cryptocurrency wallet extensions by their internal identifiers. These include MetaMask, Phantom, Coinbase Wallet, Exodus Web3, Trust Wallet, Keplr, and many others. Desktop wallet applications are also targeted. SHub collects local storage data from 23 wallet apps, including Exodus, Electrum, Atomic Wallet, Guarda, Coinomi, Sparrow, Wasabi, Bitcoin Core, Monero, Litecoin Core, Dogecoin Core, BlueWallet, Ledger Live, Ledger Wallet, Trezor Suite, Binance, and TON Keeper. Each wallet folder is capped at 100 MB to keep the archive manageable. Beyond wallets and browsers, SHub also captures the macOS Keychain directory, iCloud account data, Safari cookies and browsing data, Apple Notes databases, and Telegram session files—information that could allow attackers to hijack accounts without knowing the passwords. It also copies shell history files (.zsh_history and .bash_history) and .gitconfig, which often contain API keys or authentication tokens used by developers. All of this data is compressed into a ZIP archive and uploaded to res2erch-sl0ut[.]com/gate along with a hardcoded API key identifying the malware build. The archive and temporary files are then deleted, leaving minimal traces on the system. The part that keeps stealing after you’ve cleaned up Most infostealers are smash-and-grab operations: they run once, take everything, and leave. SHub does that, but it also goes a step further. If it finds certain wallet applications installed, it downloads a replacement for the application’s core logic file from the attacker’s server and swaps it in silently. We retrieved and analyzed five such replacements. All five were backdoored, each tailored to the architecture of the target application. The targets are Electron-based apps. These are desktop applications built on web technologies whose core logic lives in a file called app.asar. SHub kills the running application, downloads a replacement app.asar from the C2 server, overwrites the original inside the application bundle, strips the code signature, and re-signs the app so macOS will accept it. The process runs silently in the background. The five confirmed crypto wallet apps are Exodus, Atomic Wallet, Ledger Wallet, Ledger Live, and Trezor Suite. Exodus: silent credential theft on every unlock On every wallet unlock, the modified app silently sends the user’s password and seed phrase to wallets-gate[.]io/api/injection. A one-line bypass is added to the network filter to allow the request through Exodus’s own domain allowlist. Atomic Wallet: the same exfiltration, no bypass required On every unlock, the modified app sends the user’s password and mnemonic to wallets-gate[.]io/api/injection. No network filter bypass is required—Atomic Wallet’s Content Security Policy already allows outbound HTTPS connections to any domain. Ledger Wallet: TLS bypass and a fake recovery wizard The modified app disables TLS certificate validation at startup. Five seconds after launch, it replaces the interface with a fake three-page recovery wizard that asks the user for their seed phrase and sends it to wallets-gate[.]io/api/injection. Ledger Live: identical modifications Ledger Live receives the same modifications as Ledger Wallet: TLS validation is disabled and the user is presented with the same fake recovery wizard. Trezor Suite: fake security update overlay After the application loads, a full-screen overlay styled to match Trezor Suite’s interface appears, presenting a fake critical security update that asks for the user’s seed phrase. The phrase is validated using the app’s own bundled BIP39 library before being sent to wallets-gate[.]io/api/injection. At the same time, the app’s update mechanism is disabled through Redux store interception so the modified version remains in place. Five wallets, one endpoint, one operator Across all five modified applications, the exfiltration infrastructure is identical: the same wallets-gate[.]io/api/injection endpoint, the same API key, and the same build ID. Each request includes a field identifying the source wallet—exodus, atomic, ledger, ledger_live, or trezor_suite—allowing the backend to route incoming credentials by product. This consistency across five independently modified applications strongly suggests that a single operator built all of the backdoors against the same backend infrastructure. A persistent backdoor disguised as Google’s own update service To maintain long-term access, SHub installs a LaunchAgent, which is a background task that macOS automatically runs every time the user logs in. The file is placed at: ~/Library/LaunchAgents/com.google.keystone.agent.plist The location and name are chosen to mimic Google’s legitimate Keystone updater. The task runs every sixty seconds. Each time it runs, it launches a hidden bash script located at: ~/Library/Application Support/Google/GoogleUpdate.app/Contents/MacOS/GoogleUpdate The script collects a unique hardware identifier from the Mac (the IOPlatformUUID) and sends it to the attacker’s server as a bot ID. The server can respond with base64-encoded commands, which the script decodes, executes, and then deletes. In practice, this gives the attackers the ability to run commands on the infected Mac at any time until the persistence mechanism is discovered and removed. The final step is a decoy error message shown to the user: “Your Mac does not support this application. Try reinstalling or downloading the version for your system.” This explains why CleanMyMac appeared not to install and sends the victim off to troubleshoot a problem that doesn’t actually exist. SHub’s place in a growing family of Mac stealers SHub is not an isolated creation. It belongs to a rapidly evolving family of AppleScript-based macOS infostealers including campaigns such as MacSync Stealer (an expanded version of malware known as Mac.c, first seen in April 2025) and Odyssey Stealer, and shares traits with other credential-stealing malware such as Atomic Stealer. These families share a similar architecture: a ClickFix delivery chain, an AppleScript payload, a fake System Preferences password prompt, recursive data harvesting functions, and exfiltration through a ZIP archive uploaded to a command-and-control server. What distinguishes SHub is the sophistication of its infrastructure. Features such as per-victim build hashes for campaign tracking, detailed wallet targeting, wallet application backdooring, and a heartbeat system capable of running remote commands all suggest an author who studied earlier variants and invested heavily in expanding them. The result resembles a malware-as-a-service platform rather than a simple infostealer. The presence of a DEBUG tag in the malware’s internal identifier, along with the detailed telemetry it sends during execution, suggests the builder was still under active development at the time of analysis. The campaign also fits a broader pattern of brand impersonation attacks. Researchers have documented similar ClickFix campaigns impersonating GitHub repositories, Google Meet, messaging platforms, and other software tools, with each designed to convince users that they are following legitimate installation instructions. The cleanmymacos.org site appears to follow the same playbook, using a well-known Mac utility as the lure. What to do if you may have been affected The most effective part of this attack is also its simplest: it convinces the victim to run the malicious command themselves. By presenting a Terminal command as a legitimate installation step, the campaign sidesteps many of macOS’s built-in protections. No app download is required, no disk image is opened, and no obvious security warning appears. The user simply pastes the command and presses Return. This reflects a broader trend: macOS is becoming a more attractive target, and the tools attackers use are becoming more capable and more professional. SHub Stealer, even in its current state, represents a step beyond many earlier macOS infostealers. For most users, the safest rule is also the simplest: install software only from the App Store or from a developer’s official website. The App Store handles installation automatically, so there is no Terminal command, no guesswork, and no moment where you have to decide whether to trust a random website. Do not run the command. If you have not yet executed the Terminal command shown on cleanmymacos[.]org or a similar site, close the page and do not return. Check for the persistence agent. Open Finder, press Cmd + Shift + G, and navigate to ~/Library/LaunchAgents/.If you see a file named com.google.keystone.agent.plist that you did not install, delete it. Also check: ~/Library/Application Support/Google/. If a folder named GoogleUpdate.app is present and you did not install it, remove it. Treat your wallet seed phrase as compromised. If you have Exodus, Atomic Wallet, Ledger Live, Ledger Wallet, or Trezor Suite installed and you ran this command, assume your seed phrase and wallet password have been exposed. Move your funds to a new wallet created on a clean device immediately. Seed phrases cannot be changed, and anyone with a copy can access the wallet. Change your passwords. Your macOS login password and any passwords stored in your browser or Keychain should be considered exposed. Change them from a device you trust. Revoke sensitive tokens. If your shell history contained API keys, SSH keys, or developer tokens, revoke and regenerate them. Run Malwarebytes for Mac. It can detect and remove remaining components of the infection, including the LaunchAgent and modified files. Indicators of compromise (IOCs) Domains cleanmymacos[.]org — phishing site impersonating CleanMyMac res2erch-sl0ut[.]com — primary command-and-control server (loader delivery, telemetry, data exfiltration) wallets-gate[.]io — secondary C2 used by wallet backdoors to exfiltrate seed phrases and passwords We don’t just report on threats—we remove them Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

AI coding assistants (Cursor, Claude Code, Copilot, Cline) are writing production code at scale now, and the security gaps are real. Things I keep catching in AI-generated code: Hardcoded API keys and secrets in source files SQL queries built with string concatenation Missing input validation on user-facing endpoints No authentication/authorization on new routes eval() and dynamic code execution CORS set to allow all origins Missing rate limiting on auth endpoints No Row-Level Security on PostgreSQL tables So I built "vibe-guard" - always-on security rules that AI agents follow before generating any code. What it catches: - Validates all user input with schema libraries (Zod, Pydantic, etc) - Parameterized queries only, never string concatenation - Auth required on every new endpoint - No hardcoded secrets (env vars or secret managers) - HTTPS-only cookies, proper CORS origins - Rate limiting on sensitive endpoints - RLS for PostgreSQL in any environment It's not a scanner - it prevents the problems before they exist. The AI reads these rules and avoids generating insecure patterns in the first place. Free, MIT, zero config: https://github.com/ofershap/vibe-guard Works with Cursor, Claude Code, Cline, Copilot - any editor that supports plugins. Would love security professionals' feedback on what rules to add. submitted by /u/ofershap [link] [comments]

Came across this campaign recently and thought it was worth sharing here since it directly targets developers. The setup is pretty convincing. Attackers register domains that look like legitimate Claude Code download portals and push them to the top of search results through hijacked Google Ads accounts. The page design mimics the real thing — correct logo, proper documentation layout, installation instructions in the exact format a developer would expect. At a glance, almost nothing looks off. Once a user clicks the download button, instead of getting any actual software, the site triggers mshta.exe — Microsoft's HTML Application Host — to fetch and execute a remote HTA payload directly in memory. No file is written to disk. No traditional executable is dropped. The entire infostealer runs within a single process, which makes forensic recovery significantly harder after the fact. What it steals: browser credentials, session tokens, and other sensitive data, all exfiltrated to attacker-controlled infrastructure. For developers specifically, the impact goes beyond personal data loss — compromised credentials can expose code repositories, cloud environments, and internal systems. The technique is cataloged under MITRE ATT&CK T1218.005. What makes it effective is that mshta.exe is a signed, trusted Windows binary, so many endpoint tools don't flag it by default. A few things worth watching for if you're a defender: Unexpected mshta.exe processes making outbound connections to external URLs mshta.exe being spawned by unusual parent processes Outbound connections to newly registered or low-reputation domains Full technical breakdown including the deserialization chain here: cyberupdates365.com/fake-claude-code-malware-mshta-attack Original researcher writeup (Maurice Fielenbach on Medium) has more depth on the .NET deserialization side if anyone wants to dig into the internals. Stay safe and verify your download sources. submitted by /u/Impressive_Emu5708 [link] [comments]

A few weeks ago I ran into a small but uncomfortable thought. We’re starting to run AI assistants (Claude, Copilot, coding agents, automation tools, etc.) that have full access to our machines files, terminals, projects, secrets… basically everything. And it made me wonder: What actually stops an AI tool or any process from reading sensitive files on the system? API keys Model weights Internal reports Credentials Private datasets Most of the time… nothing. So I started building a small experiment called BlockGuard. The idea is simple: Instead of trusting every process on the machine, BlockGuard locks down sensitive files by default and only allows specific processes to access them. It checks things like: executable path binary hash signature integrity level process identity If the process doesn’t match the rule → access denied. Under the hood it uses: NTFS ACL lockdown ETW file monitoring process identity validation optional DPAPI encryption It’s written in .NET 9 and runs as a Windows service. This is still an early open-source experiment, but I’d really love feedback from people who understand Windows internals or endpoint security. Main questions I'm thinking about: Are there obvious bypasses? Is ETW the right monitoring approach? What would you change in the design? Would a kernel minifilter be the real next step? Repo: https://github.com/m2l33k/BlockGuard If you work with AI agents, Windows security, or DLP systems, I’d love to hear your thoughts or suggestions. Even criticism is welcome submitted by /u/Expensive-Building94 [link] [comments]