Search/sharp
Known CVEs
0
Highest CVSS
—
In KEV
0
Vendor
nec x464un firmware
Connections
293 relationships
Tricks from the Past deployed via signed ChatGPT and Claude binaries
Key Points Check Point Research discovered a campaign we track as Yoba where attackers abuse the popularity of AI tools such as ChatGPT and Claude, creating fake GitHub projects that pretend to be desktop applications like GPT-5.6 Sol , GPT-6 Astra , and Claude Opus . The malware is placed next to legitimate, signed executables from OpenAI and Anthropic so it can be loaded indirectly, a technique commonly known as DLL sideloading, which is often used to bypass security protections. This campaign demonstrates strong operational security (OPSEC) by avoiding dedicated command-and-control (C2) infrastructure and instead relying on Telegram, Tor, Catbox, and DNS over HTTPS (DoH). The actor behind the campaign shows indicators that suggest Russian origins and appears to operate primarily in the UTC-4 time zone. Introduction Over the past two months, we have been tracking a campaign that abuses the popularity of AI tools such as ChatGPT and Claude to spread a custom malware chain we call Yoba . The attackers use fake GitHub projects that pretend to be AI desktop applications like GPT-5.6 Sol , GPT-6 Astra , and Claude Opus . These projects look convincing and use real GitHub infrastructure, which helps them appear legitimate to potential victims. The website exhibits search-targeted content and suspicious installer-delivery tactics consistent with an SEO-poisoning lure. Inside the installers, there is a malicious component we refer to as the YobaDropper . This dropper includes another component, the YobaLoader , which is responsible for contacting attacker-controlled infrastructure and fetching the final payload. In this report, we describe how victims are lured to these fake projects, how the YobaDropper and YobaLoader work together, and how the attackers ultimately use this chain to run unwanted software on infected systems. Figure 1 — GPT-6 Astra campaign, attack chain. GitHub Repositories The initial access occurred via malicious GitHub repositories. The projects were impersonating ChatGPT and Claude related models, more specifically GPT-5.6 Sol, GPT-6 Astra, and Claude Opus. No manipulation of fake engagement (stars/forks) was in place. Figure 2 — GitHub repository. Aside from the repositories, GitHub.io pages were used to describe the capabilities of the software, while the malware was hosted as a release. Figure 3 — GitHub.io page with links to malicious release. These phishing landing pages contain download links that point directly to the malicious ZIP releases hosted on GitHub. Figure 4 — Claude Opus GitHub[.]io page. While the repositories do not show signs of fake engagement (such as artificially inflated stars or forks) that would promote them within GitHub’s own search, they still appear among the top results on Google. This is most likely due to SEO poisoning, where the attackers optimize titles, descriptions, and hosting domains to make their malicious projects rank highly in external search engines. Figure 5 — Google Search results. Each repository uses a different email address ( edwardcarlsonmkym[@]outlook[.]com , daxschneiderdjuu[@]outlook[.]com , and rioprestonlfyx[@]outlook[.]com ), and the uploader appears to operate in UTC+4 , UTC-4 , and UTC+3 respectively. This inconsistency likely reflects a deliberate attempt to obscure the threat actor’s true operational timezone. Repositories’ initial commits: Repository: /gpt-5-6/sol-free-desktop ================================================== [2026-07-16T14:39:40Z] Author: gpt-5-6 tree aebceccb0f3303806c35a73da865b684594487c1 author gpt-5-6 <[email protected]> 1784212780 +0400 committer GitHub <[email protected]> 1784212780 +0400 Initial commit ================================================== Repository: /gpt-5-6/gpt-5-6.github.io ================================================== [2026-07-16T14:44:31Z] Author: gpt-5-6 tree 249dae41d64583a6a9ebcb60e3ad36d6216dd6e4 author gpt-5-6 <[email protected]> 1784213071 +0400 committer GitHub <[email protected]> 1784213071 +0400 Initial commit ================================================== Repository: /opus-5-0/opus-5-0.github.io ================================================== [2026-08-31T21:33:26Z] Author: opus-5-0 tree 46ae1f147cf70d4df1471f0e9df46b654d11fe9c author opus-5-0 <[email protected]> 1788212006 -0400 committer GitHub <[email protected]> 1788212006 -0400 Create readme.md ================================================== Repository: /gpt-6-astra/gpt-6-astra.github.io ================================================== [2026-09-04T22:56:13Z] Author: gpt-6-astra tree 028bfd4c1041dc1f030c9480a463366e6089e661 author gpt-6-astra <[email protected]> 1788562573 +0300 committer GitHub <[email protected]> 1788562573 +0300 Initial commit ================================================== Although the first repository was created around July 2026, the first two malicious releases were not uploaded until the end of August, and a third malicious release followed approximately five days later. Release: /gpt-5-6/gpt-5-6.github.io/releases/tag/v5.6.0 [2026-08-30T19:15:44Z] gpt-5-6 Uploaded sol-setup.zip (application/zip) (269) ================================================== Release: /opus-5-0/opus-5-0.github.io/releases/tag/Release_v5.0.0 [2026-08-31T21:38:13Z] opus-5-0 uploaded Setup-Claude.zip (application/zip) (82) ================================================== Release: /gpt-6-astra/gpt-6-astra.github.io/releases/tag/Astra [2026-09-04T23:14:11Z] gpt-6-astra Uploaded GPT-6-Astra-Setup.zip (application/zip) (352) Malicious zip files hosted on GitHub and other legitimate platforms are usually password-protected , since this prevents automated tools from unpacking and therefore analyzing them. However, neither of these repositories used password protection, as the binaries already had very low detection rates thanks to their anti-sandbox and other anti-analysis techniques. Figure 6 — Low detection rate. While the two ChatGPT-related releases and their repositories were created about five days apart, the ZIP files contain mostly the same files, including the malicious components, and they maintain the same IoCs. Filenamesol-setup.zip (ChatGPT)GPT-6-Astra-Setup.zip151.0.7922.174.manifest2026-08-30 15:11:18N/AD3dx9_41.dllN/A2021-10-18 17:58:06owl-shell-runtime.json2026-08-30 15:11:182026-08-30 15:11:18Setup.exe2026-08-30 15:11:182026-08-30 15:11:18snapshot_blob.bin2026-08-30 15:11:182026-08-30 15:11:18v8_context_snapshot.bin2026-08-30 15:11:182026-08-30 15:11:18vk_swiftshader.dll2026-08-30 15:11:182026-08-30 15:11:18vk_swiftshader_icd.json2026-08-30 15:11:182026-08-30 15:11:18vulkan-1.dll2026-08-30 15:11:182026-08-30 15:11:18 winmm.dll 2026-08-30 15:14:20 2026-08-30 15:14:20 By adding the compilation timestamps to this these time-related operations, we are able to determine which files appear to contain the malicious functionality without performing any initial analysis. FilenameCompilation Timestamp (UTC)D3dx9_41.dll2076-06-18 21:48:40Setup.exe2026-08-19 20:00:27vk_swiftshader.dll2026-08-19 20:00:27vulkan-1.dll2026-08-19 20:00:27 winmm.dll 2026-08-30 19:14:19 The file that immediately stands out is winmm.dll , which was compiled the same day it was added to the ZIP archive. This suggests it is the component with the malicious functionality, while the other files serve to make the package appear legitimate. The compilation timestamp also indicates the actor is operating in the UTC-4 timezone . Furthermore, Setup.exe , a legitimate signed OpenAI executable, is used during execution to sideload the malicious DLL. The Setup-Claude.zip file contains the same structure, though in this case Setup.exe is a legitimate signed Claude executable. Figure 7 — Signed OpenAI and Anthropic binaries. YobaDropper – winmm.dll The malicious DLL contains multiple export names, suggesting that the legitimate winmm.dll has been spoofed. As in many other cases, these exports exist but their code has been stripped out, leaving them mostly empty and reducing the size of the binary. Figure 8 — Stripped code from exports. All 180 exports contain just a return instruction ( C3 ) followed by NOPs ( 90 ), and DllEntryPoint is the only one containing actual code. Anti-Analysis, Pre-Checks The first function implements an anti-sandbox technique: the malware hashes the basename of its host executable and checks whether the checksum matches the hardcoded value 0xE6C2F326 . The hashing algorithm has been identified as DJB2, which other malware families have also used in the past. The malware expects to run under the name Setup.exe , so this check fails if the DLL is executed on its own inside a sandbox environment. Figure 9 — DJB2 algorithm and hash check. Although a failed check does not terminate the process, the DLL performs 200,000 iterations of Sleep(5500) , amounting to approximately 12.73 days, while repeatedly appending the decoded filler string pddy to a local UTF-16 buffer. In the second function, the malware checks whether the infected user is located in a CIS country by inspecting the system’s keyboard layout. Ukraine was historically included in such checks, but it is not in the list used by recent malware. The language check is unusual. Instead of comparing the victim’s keyboard language ID against hardcoded values, the malware checks whether the ID falls within the range 0x19 – 0x44 . For IDs in that range, it tests the corresponding bit in the bitmask 0xEC0400C8401 to determine whether the language belongs to a CIS-region country, with an explicit exception for ID 0x22 (Ukrainian). Bazarloader has used a similar technique in the past, with the bitmask 0xD8080190C03 . Figure 10 — Language checks. Language IDs excluded from the infection: Russian Belarusian Tajik Armenian Azerbaijani Georgian Kazakh Kyrgyz Turkmen Uzbek Tatar The malware continues to resolve Windows API functions dynamically from kernel32.dll and ntdll.dll by comparing hashes of the exported function names. The hashing algorithm is again DJB2, with the initial value 0x1505 . The last check before the malware unpacks and deploys the embedded payload tests whether the process is running with administrator privileges. If it is not, the malware displays the message “Please run this program as Administrator.” to the victim and terminates itself, requiring the user to rerun it with elevated privileges. Deploying Phase The dropper contains multiple XOR-encrypted strings that are decrypted when needed. These strings include the file paths where the embedded binaries are dropped, as well as the decryption keys. It creates a directory under ProgramData named WMProcess . Then it copies the original WMPDMC.exe from System32 into this newly created folder. Next, it decrypts the embedded payload using the string IRANNUMBERONE as the XOR seed and drops the decrypted payload in the same folder under the name wmpdui.dll . Using scheduled tasks, the dropper maintains persistence by leveraging the legitimate executable, which will sideload the malicious payload. To make the task appear legitimate, it sets the author to Microsoft Corporation and the description to Collects device metadata for Windows Media Player. . It also sets the boot-trigger delay to PT3M , which corresponds to a 3-minute delay after system startup, and configures the task to run under the Local System account ( S-1-5-18 ). YobaLoader – wmpdui.dll The second-stage payload contains the same code as the dropper, which indicates that the same developer is responsible for both components. The same anti-sandbox technique is used, forcing the malware to be run only by WMPDMC.exe . It again checks the hash of the process basename, and only continues execution if this value matches the hardcoded hash 0x552751E3 . The dropper uses the DJB2 hashing algorithm to hash and verify the process name and to resolve Windows API functions, both with the same seed 0x1505 . The loader (YobaLoader) also uses DJB2 for the process name with the same seed as the dropper, but for resolving Windows API functions it uses a different seed, 0x1DEB . Figure 11 — Hashing windows API functions. The developer reused the same string-hashing algorithm but changed the seed ( 0x1505 in the dropper, 0x1DEB in the loader) to separate the hash spaces for each stage, complicating analysis, and reducing the effectiveness of hash-based detection and automated tooling. Network The downloader uses an interesting process to obtain the next-stage payload. It first decrypts multiple strings using a simple XOR operation, among these strings is the URL of a Telegram channel, t[.]me/yoba_fanclub . It then visits this channel using the user-agent string Mozilla/5.0 (Windows NT 10.0; Win64;) and parses the HTML source to extract the src URL of the element with the class tgme_page_photo_image . This class refers to the location where the channel’s profile image is hosted. Figure 12 — Telegram channel. It downloads the image and uses the last 50 bytes as a seed to generate a domain based on three lists of dictionary words, which are decrypted as part of the DGA algorithm. This DGA algorithm uses three sets of strings: Adjectives Nouns Verbs Finally, it generates and appends an integer value in the range 0–999 . The generated domain has the following format, "$adjective-$noun-$verb-$digit.dedyn[.]io" . By changing the image of the Telegram channel, a new domain can be generated. The following Python snippet represents the DGA algorithm: """ Author: @Tera0017/Check Point Research """ from pathlib import Path import sys ADJECTIVES = [ "silver", "amber", "wild", "tiny", "brave", "lucky", "calm", "sharp", "swift", "bright", "quiet", "bold", "gentle", "fierce", "royal", "mystic", "username", "degenerate", "allblack", "kizta", "graf", ] NOUNS = [ "tiger", "river", "stone", "cloud", "wolf", "ocean", "forest", "mountain", "eagle", "raven", "ember", "comet", "fox", "dragon", "piano", "viper", "yoba", "yyoba", "static", "cpp", "example", ] VERBS = [ "runs", "jumps", "sings", "sleeps", "flies", "hunts", "burns", "floats", "shines", "whispers", "roars", "dreams", "strikes", "glides", "watches", "hides", "duty", "free", ] FNV_MULTIPLIER = 0x1000193 MASK64 = 0xFFFFFFFFFFFFFFFF def hash_bytes(data: bytes, seed: int) -> int: value = seed for byte in data: value = ((value ^ byte) * FNV_MULTIPLIER) & MASK64 return value def generate_domain(image_path: str) -> str: image = Path(image_path).read_bytes() if len(image) < 50: raise ValueError("Image must contain at least 50 bytes") tail = image[-50:] adjective = ADJECTIVES[hash_bytes(tail, 0x811C9DC5) % len(ADJECTIVES)] noun = NOUNS[hash_bytes(tail, 0xAF0154A5) % len(NOUNS)] verb = VERBS[hash_bytes(tail, 0xFE5439E4) % len(VERBS)] number = hash_bytes(tail, 0xFFA7471A) % 1000 return f"{adjective}-{noun}-{verb}-{number}.dedyn[.]io" if name == "main": image_file = sys.argv[1] print(generate_domain(image_file)) It then queries Google’s DNS-over-HTTPS (DoH) API to obtain an encrypted command from a DNS TXT record, using a URL of the form https://dns[.]google/resolve?name=$DGA&type=TXT . By relying on a DoH service and common file-hosting platforms, the actor aims to bypass passive DNS monitoring and some gateway-based security protections, making their command-and-control traffic harder to distinguish from regular user activity. Figure 13 — DNS TXT record, base64 encoded data. It decodes the Base64-encoded data field from the JSON response and validates it using Ed25519 signature verification with the public key b5c2d20623d4e6647d06a42864edd8629f82c5c384b243fdaeeeca24b3873d64 . Once the signature validation succeeds, it decrypts the decoded value using AES in ECB mode with the key 1d0d1368b4d53f3a6322cf40e84e63db . Decrypted response: 1https://files.catbox[.]moe/z5zpy9.dat The downloader retrieves the encrypted payload and decrypts it using the same AES key and ECB mode that were previously used for the DNS data. The malware provides three methods for deploying the downloaded payload. The selected method is indicated by the first character of the decrypted response that follows the URL (1/2/3): Injects the downloaded payload into svchost.exe (NtWriteVirtualMemory/NtCreateThreadEx). It enumerates running processes and, using the hashing algorithm with the seed 0x1DEB , searches for the hash value 0xC26CDEA5 , which corresponds to svchost.exe . Saves the payload as a %TEMP%\$10_rand_char\$10_rand_char.exe file and executes it. Before running the executable, the downloader removes the Zone.Identifier alternate data stream, which is hidden metadata used by Windows to track the origin of downloaded files. Saves the payload as a %TEMP%\$10_rand_char\$10_rand_char.ps1 PowerShell script and invokes it with the following parameters: -WindowStyle Hidden -ExecutionPolicy Bypass -File . Finally, the injected payload into svchost.exe is an XMRig 6.26.0 miner with a hidden command line targeting a TLS-enabled onion mining endpoint through a local Tor SOCKS5 proxy. It can unpack and start Tor 0.4.9.12 plus lyrebird 0.8.1, monitor user-input activity to pause mining, and conditionally load the WinRing0 driver service for MSR-based mining optimization. FieldValueMining server 3zciedc3enu4muwc5adxciyk6u3juhvhvbv6bfrk2arawlvb7k7ovxad[.]onion:443 Pool password/token dcde1f56048fa18657dc4820397592f7 TLSEnabled ( --tls )Proxy socks5://127.0.0[.]1:9550 Donation level 0 CPU thread hint 85% User-active pauseResume after 240 seconds idleSingleton mutex Local\WindowsSecurity Tor data directory %TEMP%\torbundle\data Tor bridge 1 obfs4 51.89.231[.]85:24526 A44162645CEAA39C7106C49A3F36FD99FF8D8A00 cert=cVNRBh1enpvEGxA0ouu568EDFhWPl9taldydYgiJk77OX4MzoYIRz3qx4q7yHL5bRN60Gg iat-mode=0 Tor bridge 2 obfs4 51.89.228[.]250:21668 BA8BD67D8898CF378D4F73821DEB5657F4BB98DF cert=bEpLLgOwJ9fOJbeHb5r+ronUF2ck5nRd0Jl3zuy7rLoUp732QK2p/CUHjTAfBPCGfcVtSA iat-mode=0 Although we observed an XMRig cryptominer as the final payload in this campaign, the YobaLoader is a generic loader. The operator can supply any PE or PowerShell payload via the signed DNS TXT tasking, so future waves may deliver different malware families. Past Yoba Versions Yoba exposes, through the same hashing algorithm it uses for anti-analysis, the specific process name under which it expects to run. Even without having full visibility into the campaign from the very beginning, analysts can still infer which targeted software was used to lure users by correlating this expected process name with the fake AI applications promoted on the associated GitHub repositories and GitHub Pages sites. HashProcessProduct 0xE6C2F326 Setup.exeChatGPT & Claude Opus 0x56221573 Cursor.exeCursor AI Coding Agent 0x39DE0DD8 UnknownUnknown Earlier YobaDropper observed in the wild appeared in early June 2026. In this campaign, the dropper was sideloaded by a process named Cursor.exe (hash: 0x56221573 ). It remains unclear whether Cursor.exe was a legitimate signed binary. The majority of the functionality in this early variant is consistent with the newer versions of both the dropper and the loader. YobaDropper shows two main differences between its older and newer versions: Unpacking logic: In the oldest version, the buffer is first Base64-decoded and then XOR-decrypted to extract the YobaLoader . In the newer version, the developer removed the Base64-decoding step and performs only XOR decryption, simplifying the unpacking process. Execution method: The second change concerns how YobaLoader is triggered. The newer version uses Scheduled Tasks to start the copied legitimate host and sideload the loader, whereas the first discovered version creates the shortcut msdefender_scheduler{7940-8490-6670-1081}.lnk in the Startup folder. This shortcut executes a copied %APPDATA%\Microsaft Difendir\msdtc.exe and sideloads %APPDATA%\Microsaft Difendir\mswsock.dll . Earlier version of YobaLoader contains language checks and excludes only Russia from infection. In later versions, these checks were moved to the dropper stage and expanded to exclude additional CIS countries, shifting regional filtering earlier in the infection chain. Figure 14 — Exclusion of Russian language from infection. While the overall DGA logic remains the same, the early variant uses the extension .aber[.]ir instead of .dedyn[.]io . In addition, instead of injecting into svchost.exe , this variant injects into a different running process identified only by its hashed name 0x21BD94C2 . The initial loader also implements several anti-analysis techniques that have been removed from the newer versions of the malware: 1. Anti-debugging It enumerates all kernel object types and reads their TypeName values. Each type name is hashed using DJB2 with the seed 0x1DEB until the hash matches 0xCF9EE149 , which corresponds to DebugObject . If a DebugObject is found, it indicates that a debugger is or was active, and in that case the malware terminates itself. Figure 15 — DebugObject via NtQueryObject-ObjectAllTypesInformation. 2. Anti-VM The malware uses a VM/sandbox-detection scoring function while running several hardware fingerprinting checks. The maximum score is 6, and the minimum required to continue the infection chain is 3. The checks include: Hypervisor-present bit and CPUID timing (via RDTSCP ). Hypervisor vendor signature string (CPUID leaf 0x40000000 ). CPU brand string sanity checks (CPUID leaves 0x80000002 – 0x80000004 ). SMBIOS-based firmware fingerprinting ( GetSystemFirmwareTable – RSMB ) Figure 16 — Hypervisor vendor signature string technique. Despite these small differences in early anti-analysis behavior, the Telegram channel and the profile image used as the seed for the DGA remain the same as in the newer variants, indicating that the operator retained the same infrastructure while iterating on the loader’s evasion logic. Conclusion The Yoba campaign shows how attackers can use trusted platforms and the current interest in AI tools to distribute malware in a way that looks believable and harmless at first glance. By packaging their code together with well-known software names and hosting it on GitHub, they lower the chances that users or basic security checks will immediately flag the files as suspicious. Although the underlying techniques are more advanced than typical commodity malware, the main goals remain straightforward: gain a foothold on the victim’s system, avoid easy detection, and then run the attacker’s chosen payload. Organizations should be cautious about installing “AI helpers” or similar tools from unverified repositories and should enforce policies that restrict running software from unknown sources. Combining user awareness with basic technical controls. Indicators of Compromise DescriptionValueGitHub pagesgithub[.]com/gpt-5-6/sol-free-desktop gpt-5-6.github[.]io github[.]com/gpt-5-6/gpt-5-6.github.io github[.]com/gpt-6-astra/gpt-6-astra.github.io gpt-6-astra[.]github[.]io opus-5-0[.]github[.]io github[.]com/opus-5-0/opus-5-0.github[.]ioZIP Files332e3b685e375aa44a5ec98511fc53be821df46a c2b986704406d47dd88ee4e2fcffebc854ff2ce4Signed OpenAI & Anthropic binaries163c81187d8024123912c3c12d905fd5210afcb3 65a3ac8f341ae04982005fd2c4e83627a68793a3YobaDropper17e8639a00bb32b10cb9cf0d292e9441456ce4bb 20238b36645fc63139a76b19a480c6a9166472fa 4ea5b71202b69fc27b06ef9ee3f6f51d6f7b8586 60aece343959a2e1840f6aaeffa38b73ed21af2c 8777db31d8df78f36e4544a132d843dfb2a0f026YobaLoader22661f4bada8167fa0f410b75e53184998990abb 2ecb5548e9774a3d05e8669e8414dcc366929b79 3fef1af3664429e621d3e0f9408cb5102ef02b84 55043ea6d102670c014e2be5a8197e70b7c201cb 79e87a6df59d68b2dbd2c43950df5663d671007c 7dfcee02732ed89f1ddf25d1689863c26de3df15 bead5748d813a9828ddb7603a32e52aa15349768 cf90c4599257e76984a199d98b1fd082b820a54d eeedc5c9007d7f01808285e0ae0c0b451bdba003Telegram imagee7c0e981f81447892995d01ed986c0b462a6f0c5Telegram Channelt[.]me/yoba_fanclubDNSdns[.]google/resolve?name=calm-piano-floats-313.dedyn[.]io&type=TXTITW URLfiles.catbox[.]moe/z5zpy9.datEncrypted Payload7467b6980440ec27c4e0a8d940672c9f24e14216Payload XMRIGea16728f6928dc77deaddee74a6e736dd5f24fc5XMRIG Endpoints3zciedc3enu4muwc5adxciyk6u3juhvhvbv6bfrk2arawlvb7k7ovxad[.]onion:443 51.89.228[.]250:21668 51.89.231[.]85:24526 Yara Rules rule yoba_dropper { meta: author = "@Tera0017/Check Point Research" description = "YobaDropper" strings: $code1 = {00 BB 40 0D 03 00 B9 7C 15 00 00 FF D6 31 C0} $code2 = {BA 05 15 00 00 0F BE 08 84 C9 74 0A 6B D2 21} $code3 = {53 B9 75 EE 40 70 48 83 EC 20} $code4 = {BA 5C CD 17 E5 48 89 C1 E8 73 00 00 00} $code5 = {0F C8 89 C0 4? 39 ?? 74 1? (49 0F AF C0| 48 69 C0 ?? ?? ?? ??) (4C 01 C8| 48 05 ?? ?? ?? ??) 49 89 C? 49 C1 E? 18 45 30 [2] 4? FF ?? EB} condition: uint16(0) == 0x5A4D and 2 of them } rule yoba_loader { meta: author = "@Tera0017/Check Point Research" description = "YobaLoader" strings: $code1 = {B9 80 A8 12 01 FF ?? ?? E9} $code2 = {BA EB 1D 00 00 0F BE 08 84 C9 74 0A 6B D2 21} $code3 = {B9 5B 80 EF B7 E8} $code4 = {BA F5 8B 2E F2 48 89 C1} $code5 = {B5 C2 D2 06 23 D4 E6 64 7D 06 A4 28 64 ED D8 62 9F 82 C5 C3 84 B2 43 FD AE EE CA 24 B3 87 3D 64} $code6 = {1D 0D 13 68 B4 D5 3F 3A 63 22 CF 40 E8 4E 63 DB} $code7 = {40 80 FE 32 74 42 40 80 FE 33 74 66 40 80 FE 31} $code8 = {41 81 F8 A5 DE 6C C2} condition: uint16(0) == 0x5A4D and 2 of them } The post Tricks from the Past deployed via signed ChatGPT and Claude binaries appeared first on Check Point Research .
research.checkpoint.comOct 27, 2026extracted
Deploying AI agents securely: how Kaspersky products mitigate AI threats
Introduction AI agents and associated tooling are becoming increasingly common in corporate infrastructure. Agents can perform a range of actions with the user’s privileges, such as accessing data, running commands, and interacting with external services. This creates new security risks, especially when these tools are used without the security team’s oversight or well-designed policies. Detecting, tracking, and controlling AI agents is becoming one of the most pressing tasks for security teams today. We closely follow technological developments and continuously update our solutions to respond to new threats in a timely manner amid a rapidly changing technology landscape. This post describes new expertise built into Kaspersky products that helps counter the threats posed by the proliferation of AI agents. We approach this problem from several angles. First, you need to thoroughly understand the threat you are dealing with. To this end, we added profiles to the Kaspersky Threat Intelligence Portal that describe various AI agents and how attackers exploit them. At their core, AI agents are programs (processes) that run in the operating system on endpoints and can also launch other processes. This means that Endpoint Detection and Response solutions are among the key endpoint controls for this threat. These solutions detect the presence and launch of AI agents, track their activity, and identify potentially dangerous behavior. When needed, they also take action, such as stopping a suspicious process, blocking the activity, or isolating the host, to reduce the likelihood of an incident escalating. For this purpose, we developed specially adapted detection rules. You can use Kaspersky Endpoint Security, now also available as Kaspersky Next , to control and restrict the launch of AI agents. This solution uses two components to detect AI agents and control how they are used. Application Control categorizes the application processes launched on endpoints, and Web Control manages access to specific categories of web resources for users on endpoints. Finally, even harmless AI agents can contain malicious instructions (skills), such as those downloaded from unsafe external sources. Kaspersky Scan Engine analyzes installed applications to detect these threats and also checks LLM files for malicious code. Let’s take a closer look at these solutions and technologies. Popular AI applications and services in organizations Tools from Anthropic and OpenAI take the top spots in the September 2026 ranking of AI agents by popularity among Kaspersky users. This list is based on telemetry from Kaspersky solutions. It shows the number of users who had the relevant AI vendors’ products installed at the time of the study. # AI product 1 Claude 2 Claude Code 3 Codex 4 OpenCode 5 Zed 6 Wispr Flow 7 LM Studio 8 ZCode 9 Chatbox 10 Cherry Studio The data shows that agentic systems, especially AI agents for software development, are the most popular AI applications. The TOP 10 also includes an application for running large language models locally (LM Studio) and a voice note-taking app (Wispr Flow). According to open sources, these are the most widely used AI services in 2026: # AI service 1 ChatGPT 2 Google Gemini 3 Claude 4 Grammarly 5 DeepSeek While analyzing the most popular and widely used apps, our experts also noticed a sharp rise in vulnerable versions of AI-related software and services . From 2025 to date, more than 2500 vulnerabilities have been published: Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 ( download ) * Data for previous quarters was updated and may differ slightly from previously published data. Application Control and Web Control To enforce the organization’s security policy for AI agents and other AI applications on the corporate network, Kaspersky products offer application control based on KL categories . These categories classify installed software and give you granular control over which approved applications can run in the organization. Application Control analyzes the processes launched on endpoints, tracking which AI agents are running in corporate systems at any given moment, on which hosts, and under which accounts. Application Control also shows how long a given program has been in use. This makes it easier for the Kaspersky Security Center (KSC) administrator to control applications. Administrators can use KL categories to allow or block AI agents inside the company for specific groups of employees. Here is what this functionality looks like to KSC administrators: KL categories available when configuring Application Control For details on how to configure Application Control in KSC, follow this link . In Kaspersky Endpoint Security (KES), Application Control can operate in two modes: Denylist . In this mode, Application Control lets users run any applications except those blocked by Application Control rules. This is the default mode. Allowlist. In this mode, Application Control blocks users from running any applications except those explicitly allowed by Application Control rules. Below are the steps to configure Application Control to block AI tools. Configuring Application Control for the AI Tools category in KES With this setup, when a user tries to launch an AI agent, they get a notification and the agent doesn’t start. KES notification about an attempt to launch an AI agent For more on how to configure Application Control in KES, follow this link . Our public portal also lets you explore information on KL categories and the applications that fall under them, in particular details on how AI agents are categorized and how popular they are . AI Tools KL category The View applications drop-down list shows products for a specific vendor. Similarly, Web Control lets you manage user access to web resources. If a user tries to open a denylisted website, KES blocks access and shows a warning. KES notification about an attempt to access a prohibited web resource When configuring access, the administrator can block websites that provide AI as a service. Website categories For more on configuring Web Control, follow this link . The help portal also provides information on website categories that can be assigned to resources to configure access control. Kaspersky Endpoint Detection and Response To an EDR solution, an AI agent is a regular process. It has its own executable, a tree of child processes, and network communications, all of which need to be monitored for suspicious activity. An attacker can use an AI agent as an automation tool. An AI agent installed as a legitimate user tool can also be leveraged in a ClickFix attack, where it executes a malicious instruction received from an untrusted source, such as a document, web page, or email. That said, unsafe actions by an agent do not always indicate an attack. There may be no malicious intent in the chain at all. An incident can result from what looks like an ordinary instruction from a user who doesn’t fully understand the consequences of having it executed. The mere fact that an agent was launched does not reveal whether it is being used in an attack. That is why Kaspersky EDR (KEDR) uses both conventional behavioral rules and rules written and adapted to detect AI tools. The latter identify risky agent actions and settings, and help determine which AI tool was involved in suspicious activity. Conventional KEDR rules detect the vast majority of familiar malicious techniques, including when performed by an AI agent. A suspicious PowerShell launch, persistence via Task Scheduler, or an attempt to steal credentials leaves clear, identifiable traces. These traces look the same no matter what initiated the actions. The rules analyze launch parameters, process relationships, affected files, network activity, and other telemetry events. For example, in a recent Armored Likho campaign , we found signs that AI had been used to create loader and dropper samples, which were later compiled with NSIS (Nullsoft Scriptable Install System). The key telltale artifacts were icons in the scripts and excessive comments on every function, which is uncharacteristic of human-written code. In addition, the group continues to generate new modules for its BusySnake Stealer and BusySnake RAT samples. For example, the attackers used AI to develop a module that runs multiple checks for virtual environment artifacts and calculates a score. Depending on the score, the sample either runs or exits with code 0. Even though the initial access samples, payloads, and their modules were AI-generated, the commands they execute via rundll32 and PowerShell are detected by the shell_creation_by_rundll32 and suspicious_powershell_cmd_or_script_spawning rules. So, for detecting an attack like this, it is not important who wrote the loader, the payload, or its modules: they are given away by the commands they execute, process relationships, and other traces of activity in the system. AI can be involved both in preparing the code and in carrying out the attack directly on the device. In the latter case, the attacker uses the agent to carry out their tasks and lets it choose and run the required commands within the privileges it has. For effective protection, it is critical to link suspicious actions back to the AI tool and the conditions under which it operates. In KEDR, several specialized rules handle this task. We have created separate rules for popular AI agents, ai_agent_*_access_to_sensitive_file_ , where * is the tool name and is the operating system. They generate alerts when an agent accesses files that contain credentials, tokens, or keys. ai_agent_opencode_access_to_sensitive_file_win Tap to previewTap to hide The ai_agent_dangerous_execution_mode rule detects agents launched with auto-approval of all actions (so-called YOLO mode) or with the sandbox disabled. These settings do not indicate an attack on their own, but they let the agent perform dangerous actions without user confirmation. ai_agent_dangerous_execution_mode Tap to previewTap to hide The suspicious_mcp_server_artifact rule triggers when MCP server scripts are created or modified in hidden, temporary, or cache directories. Attackers can place an MCP server in these locations to quietly connect it to the agent: through the MCP server, they can pass instructions to the agent, call third-party tools, and access the user’s data. suspicious_mcp_server_artifact Tap to previewTap to hide The llm_api_access_by_unusual_apps rule generates an alert when an application on Windows, Linux, or macOS connects to the API of a known external LLM service, unless this activity falls under predefined exclusions. This helps spot model access by applications that do not normally behave this way. llm_api_access_by_unusual_apps Tap to previewTap to hide Some Kaspersky EDR rules tag events for investigation but do not generate alerts. For example, the ai_agent_**_execution rules flag launches of known agents on Windows, Linux, and macOS. The local_ai_model_artifact rule records the creation or modification of AI model files in typical application, runtime, and cache directories. These events reveal AI tools on the device, including tools that run on local models and never call an external API. local_ai_model_artifact Tap to previewTap to hide Kaspersky Threat Intelligence Portal AI agent profiles The Kaspersky Threat Intelligence Portal offers a large number of software profiles, including profiles of AI agents. You can sort them by the ai_ prefix: AI agent profiles on Kaspersky TIP The profile of an AI agent such as Claude Desktop includes a detailed description of the software, the privilege level required to run it, supported platforms, and threat actor groups known to use it. It also lists tactics and techniques mapped to the MITRE ATT&CK framework, with descriptions of the procedures the tool can be used for. Claude profile on Kaspersky TIP The description also lists ways to detect the software through standard system auditing mechanisms: Windows: events from standard audit logs and Sysmon events Linux: syscall audit events and Sysmon events Network auditing: a set of protocols and the traffic generated by the software The detection section lists the main artifacts the software leaves in the system: command lines, possible launch parameters, names of the services and scheduled tasks it creates, and the key network artifacts. Detection section in the Claude profile Hunt Hub In December 2025, the Kaspersky Threat Intelligence Portal added Hunt Hub (HH), a repository of detection rules. This is a unique Kaspersky project, and we developed it in response to growing market demand. This functionality is available in the Threat Landscape section of the portal. It gives analysts access to detection rules: their descriptions and their mapping to MITRE ATT&CK tactics and techniques, as well as to the associated cybercriminal groups. In the Hunt Hub section, customers can explore the detection logic of EDR, NDR, and NGFW products, including the logic for detecting AI agents. Rules in the Hunt Hub repository The rule card provides: Detailed description Rule’s severity level, confidence level, and alert format Detection tips Description of possible false positives Platforms the rule can run on Tactics, techniques, and sub-techniques covered by the rule Groups that use the technique covered by the rule Detection logic that shows what exactly triggers the rule Detection rule card in Hunt Hub Kaspersky Scan Engine Skills are a key component of the AI agent ecosystem. They’re prewritten sets of natural-language instructions that extend agent functionality. We previously covered the risks that malicious skills pose to agent users. A skill can require the usage of additional programs and services, come with helper scripts (for example, written in Python), or contain a malicious command embedded right in the instruction text. This means that adding skills to an originally harmless AI agent opens up several new ways for malicious code to enter the system. To prevent this, any skills obtained from external sources must be scanned. Kaspersky Scan Engine is well suited for this task. This is a cyberthreat detection and response solution that seamlessly integrates with various applications. It can detect malicious code in agent skills, associated scripts, and in files generated by running agents. Detection of a malicious agent skill in Kaspersky Scan Engine Trained LLMs come in many formats. Some of them (PTH, PT, PKL, KERS, and others) also store parameters and weights (training datasets). These files can also contain malicious code, so it’s critical to scan them before running and using them. Kaspersky Scan Engine scans potentially dangerous LLM formats for infected data. It can deserialize and analyze models to detect malicious code regardless of model size. Detection of an LLM with malicious code in Kaspersky Scan Engine Conclusion AI agents are rapidly making their way into corporate environments: they help employees work faster and take on a wide range of tasks, but they also open up new opportunities for attackers. To take advantage of this technology without compromising security, organizations need to build multi-layered protection and minimize risks. A range of Kaspersky solutions can help with this: Kaspersky TIP keeps you up to date on current scenarios in which attackers use AI agents, and its Hunt Hub section provides rules for detecting suspicious AI agent activity. Kaspersky EDR detects AI agents in the infrastructure and monitors their activity on endpoints. If it detects potentially dangerous actions, the product can log the event, notify the SOC, and take response actions, such as stopping the process or isolating the host. Application Control in Kaspersky products can fully restrict the use of AI agents within the company by using application categorization. The Web Control component can restrict access to AIaaS web resources. Kaspersky Scan Engine can be integrated into various company processes to detect malicious code in any files, including AI agent skills and LLMs. When companies combine the tools described above in a comprehensive approach, they can adopt AI agents in an informed way: with an understanding of the associated risks and effective means of minimizing them.
securelist.comOct 26, 2026extracted
Malwarebytes earns another Top Product award in independent testing
Every few months, Malwarebytes gets a chance to test its mettle against real-world threats in an independent laboratory setting. And the latest round of results gives us plenty to celebrate.   Malwarebytes earned a perfect 18 out of 18 and received another Top Product award from AV-TEST. We also achieved Level 1 Certification from MRG Effitas, and we stopped 100% of threats before they could run in the two latest tests from AVLab Cybersecurity Foundation.  AV-TEST Windows Consumer Security Product Test With 18 out of 18 points in AV-TEST’s latest Windows Consumer Security Product Test , Malwarebytes nabbed the organization’s Top Product award for the July/August test cycle. AV-TEST evaluates security products across three key areas: protection against malware , impact on device performance, and the frequency of false positives. Products need at least 17.5 out of 18 points to earn AV-TEST’s Top Product award, and Malwarebytes received full marks across the board. Since we first began participating in the test in 2018, we’ve secured the Top Product award more than a dozen times. MRG Effitas Consumer Assessment   Malwarebytes also received a Level 1 Certification in MRG Effitas’ July 2026 Consumer Assessment & Certification Programme , which tested eight security products against malware, phishing , and false positives.   The malware test used 300 live, in-the-wild samples, including Trojans, spyware , ransomware, backdoors, malicious scripts, and financial malware. Malwarebytes blocked every one of them, stopping 99% before they had the chance to run, and the remaining 1% after they began behaving maliciously.   Our product also generated zero false positives across 100 legitimate apps and blocked all five live phishing sites included in the test.  Malwarebytes was one of just two products to earn Level 1 Certification, the highest level awarded in the assessment.  AVLab Cybersecurity Foundation Advanced In-the-Wild Malware Test   Meanwhile, the results from AVLab Cybersecurity Foundation’s Advanced In-the-Wild Malware Test brought more good news: Malwarebytes keeps getting better at stopping threats before they can run.  As part of the test, AVLab Cybersecurity Foundation uses threats circulating online and delivers them in ways designed to replicate how people encounter attacks in the real world.  During both the May and July 2026 tests, Malwarebytes stopped 100% of threats before they could run.  These latest results join a growing list of honors , including a Best of CNET award and ZDNET’s Editor’s Choice award. Independent testing helps keep us sharp. We’re proud to see our work recognized, and even prouder to keep delivering the top-notch protection our customers have come to rely on.  “One of the best cybersecurity suites on the planet.”   According to CNET.  Read their review →
malwarebytes.comOct 1, 2026extracted
Fewer women than ever in UK's 'old boys' club' cyber industry
The proportion of workers in the UK cybersecurity industry identifying as women has dropped to 16 percent, the lowest level since 2021. Gender diversity has long been an issue pervading the STEM fields, although in cybersecurity this is especially pronounced, both at senior leadership and education levels. This is despite evidence that girls regularly outperform boys in STEM subjects at UK schools when they do participate. Not only are there still fewer women students in cybersecurity courses than those opting for computer science, but the percentage of women in the senior workforce (6+ years of experience) drops further to 12 percent – a figure that has remained broadly consistent since records began. For context, the UK average across all industries for female-identifying workers is 48 percent. Across the digital workforce, as of last year’s data, the average is 30 percent. The UK government interviewed various stakeholders in the cyber industry, finding that the barriers to senior leadership positions were structural – employers are purposely excluding women at higher levels. History plays a part too – older heads remaining in their positions from back when gender diversity was a matter less discussed – but recruiters say employers are still holding women back based on their perceived family ambitions. One recruitment agent was quoted in the report as saying: “When I’ve spoken to a business and said to them ‘why don’t you hire a more diverse workforce?’ You’ll get the normal common ones of ‘well if we hire a female, she’ll get pregnant, she’ll be off for 12 months,’ which isn’t right.” Refusing to hire women based on assumptions or fears about future pregnancy is a form of illegal gender discrimination that directly violates the UK's Equality Act 2010. Other common barriers to senior positions include assumptions they did not have the requisite technical skills for the role, and that cybersecurity is still seen as “an old boys’ club.” “This tied into a broader finding that stereotypes about women not being interested in cybersecurity continued to persist,” the report noted. “A cybersecurity firm noted that during a career talk on cybersecurity, a group of girls walked out of the talk, and the careers teacher reinforced the perception that the sector did not appeal to women.” The business told the government: “I went to the careers lady ‘What was the story with the five girls that left?’ And she went ‘Oh, cyber security is not really a girl’s job’.” Jill Broom, head of cyber resilience at techUK, said the onus is on employers to work harder on breaking down the lingering stereotypes about women in cybersecurity. “Cybersecurity underpins our growth, our economy and the safety of our society, with the sector offering growing employment opportunities and career prospects,” she told The Register. “However, the underrepresentation of women in this industry remains a significant concern. “A lack of gender diversity not only limits opportunities for women to benefit from this growing sector but also risks narrowing the range of perspectives and ideas that are essential to tackling increasingly complex cyber threats. Educators and employers must work together to challenge stereotypes, break down barriers and promote cybersecurity as an accessible and inclusive career path.” Representation for other groups fared comparatively better. This past year set a new record for neurodivergent workers in the cybersecurity industry, with 22 percent of UK staff identifying as neurodivergent. The figure represents a sharp increase from 16 percent the year before, one that has grown each year consistently since the 9 percent reported in 2020, and exceeds the digital sector average of 19 percent. “Cybersecurity is the most neurodiverse sector I have ever seen, and I think personally it’s celebrated, especially internally within the sector,” one respondent from a small cybersecurity business told the report's authors. While this year’s results may prove especially welcome to the neurodiverse crowd, the report noted this may reflect the rising awareness of neurodiversity among employers, rather than a true increase in numbers. The representation of ethnic minorities also remained at 19 percent, the same proportion as in 2025’s data, although this was a modest rise from 2024, in which 13 percent were from ethnic minorities. The figure is aligned with the digital sector average of 20 percent, and exceeds the UK’s pan-industry average of 16 percent. However, the representation of these groups suffers at the senior levels. The proportion of ethnic minorities in senior positions stands at 9 percent, a low figure that has persisted for the third year running, and one that is considerably down from the 15 percent high of 2021. As for explanations, the report offered few. “Ethnicity was hardly mentioned and was not generally felt to be an issue, despite the quantitative findings suggesting ethnic diversity at senior levels has remained lower than in the 2021 to 2023 studies,” it stated. “Most commonly, participants did not offer any concrete suggestions for enabling the progression of staff from diverse backgrounds into senior cybersecurity positions. Some employers stated that career development was open to everyone and was based on merit.” For neurodivergent security pros, it was not their technical abilities holding them back, but some said a lack of soft skills may hinder them in senior-role scenarios. “They’re more than capable of doing a leadership role,” said one small cybersecurity business. “It’s just they might not be soft-skilled enough to deal with difficult teams, difficult conversations. But to be honest, I’ve seen some fantastic people who are neurodiverse in leadership roles.” Disabled people are continuously absent from the workforce too, occupying just 9 percent of UK roles and 5 percent of senior positions. This is both less than the digital sector average of 15 percent, and significantly less than the UK’s pan-industry average of 18 percent. ®
theregister.comOct 1, 2026extracted
Nearly two-thirds of tested websites fail every bot test
Nearly two-thirds of tested websites fail every bot test Malicious bot activity increased 124% between July 2025 and June 2026, compared with 13.2% growth in human traffic. Traffic from AI agents and large language model crawlers rose 82.3% during the same period, according to DataDome’s State of Bot & Agent Security Report 2026. Bot traffic grows nine times faster than human traffic The company analyzed trillions of requests across more than 75,000 customer sites during the 12-month period. Bots and AI agents generated approximately 26.5% of all traffic in the dataset. Percentage growth in traffic type over a 12-month period (Source: DataDome) Human traffic’s share of requests declined, and bad bots accounted for most of the change. AI traffic also grew more than six times faster than human traffic. Scraping, scalping, spamming and DDoS activity increased during the study period. Credential stuffing remained flat on an annual basis, with sharp drops and resurgences throughout the year. Web scraping was the dominant attack type, accounting for 70.9% of bad bot traffic. The availability of scraping tools and demand for data at scale continue to drive these campaigns. Credential-stuffing campaigns followed a recurring pattern. Attackers launched high-volume attacks, withdrew to refresh credential lists and rotate infrastructure, then returned at full scale. In a 30-day sample of bad bot traffic, simple bots represented the largest share. They require little effort to operate and remain effective against websites with limited bot protection. Attackers use them for scanning, reconnaissance and attacks on easier targets. Average-complexity bots are common in scraping, fake-account creation and credential-testing campaigns. They use browser automation frameworks that reproduce parts of a legitimate browsing session and make automated activity harder to identify. Advanced operators tend to keep sophisticated tools separate from basic bots to avoid exposing a campaign through simple automation signals. Some campaigns combine simple and average techniques, starting with basic automation and switching to more convincing browser simulation when needed. Browser-side signals cannot provide complete coverage. Attackers can suppress or imitate them, and requests targeting APIs, mobile endpoints or server-side services may never execute client-side code. AI agents are entering sensitive areas Monthly AI bot traffic to login pages increased more than eightfold during the first half of 2026. The increase shows the growing use of assistants that can perform tasks for users, including checking orders, retrieving account information and supporting purchases. “Organizations are being asked to make more nuanced decisions with defenses that are still largely built around binary choices,” said Jerome Segura, VP of Threat Research at DataDome. “The ability to distinguish a legitimate AI assistant from a credential-testing bot or an automated account-abuse campaign will be critical to protecting customers without blocking beneficial activity.” Login pages are also a target for bots testing stolen usernames and passwords. Shopping carts can be manipulated to reserve inventory or exploit promotions. Payment pages attract card-testing tools, and online forms remain targets for spam, false leads and automated data collection. A single request may not reveal a visitor’s purpose. An authorized assistant checking an order can initially resemble a bot attempting to access a customer account. Security systems need to examine the sequence, speed, volume and context of each interaction. Malicious software can copy the user-agent string of a recognized AI service and present itself as a trusted crawler. An unfamiliar bot can avoid rules created for known services. Most websites miss automated threats About 65.3% of the popular websites tested failed to detect any of the 10 simulated bots. Only 2.4% stopped or challenged every type. The tests covered simple scripts, bots posing as recognized AI services, tools with forged browser fingerprints and automated versions of real browsers. Requests were sent through residential internet addresses in the United States, Canada and France. Traffic volume offered little indication of protection. High-traffic websites performed at a similar level to sites with smaller audiences. Large organizations may have substantial security budgets, yet complex infrastructure, disconnected tools and legacy systems can leave gaps. Testing focused on the homepages of 21,491 popular websites. Some protections may operate on login, account or payment pages and were outside the scope of the test. Traffic classified as an attack represents an attempted action, not a successful attack, confirmed breach or financial loss.
helpnetsecurity.comSep 23, 2026extracted
The AI security question leaders should be asking instead
The AI security question leaders should be asking instead In this Help Net Security interview, Frederic Bull, Security Officer at Gremlin, talks about what AI means for security teams. The conversation covers why asking what data a model was trained on is only part of the picture, and why least privilege and access controls still matter for AI agents. It also looks at how AI has narrowed the skill gap between attackers and defenders, how the team handled about nine times as many vulnerabilities with the same staff, and why hiring now favors people with the experience to catch confident but wrong AI output. When you talk to other security leaders right now, what’s the one AI-related question you’re tired of answering, because everyone’s asking it and nobody’s asking the better question underneath it? The question I hear more often than anything else is: “What data was this model trained on?” The underlying concern driving this is confidentiality. Companies want to ensure their intellectual property won’t become part of an AI’s general knowledge. That is a valid concern, and it would be folly to imply otherwise, but stopping there leaves gaps in a true layered security approach. A far less frequently asked question is: “How do you maintain authority and integrity of the data in question.” And we have clear answers. For many years the principle of Least Privilege, achieved through Authentication & Access controls, has remained paramount to ensuring secure environments, and continues to be. Technologies such as session-based RBAC via OIDC/OBO and appropriate permission scoping for the context, ensure AI’s don’t exceed the capabilities expected of them. This has been the bedrock of enterprise security programs for decades, and it is just as relevant today. By continuing to implement modern solutions like session-based RBAC and appropriately scoped permissions, we can guarantee that AI agents never exceed their technical capability. As agent-to-agent communications become more prevalent these strategies provide for more strict ‘human-in-the-loop’ architectures, ensuring operators are positioned to recognize and correct issues before damage occurs. Walk me through what an attacker’s toolkit looks like differently now compared to three years ago. What’s new versus what’s just faster? I don’t want to downplay the significance of increased speed. Ultimately that is how this risk presents itself in the real world, and speed is paramount. Even state actors are racing against clocks to find and exploit before others discover the flaws. We are seeing a sharp increase in the vulnerability reporting over the last year, NVD has had to reprioritize classifications, leaving a great number of reported vulnerabilities unclassified. They simply can’t handle the increased volume of reports. However, the mechanism behind the elevated risk is not simply speed, it’s an erosion of the asymmetry of ability that the security industry has historically benefitted from. To find the conditions allowing for an exploit, design and test that exploit, and employ it, typically required a great deal of ability and/or expertise. AI has taken that asymmetry much closer to even. Not only can those exploitable contexts be found more quickly, but the method to leverage that can be devised and implemented by those who otherwise lack the ability, and increasingly, faster than those with the ability. That is going to continue to be a more significant factor as the contextual data AIs receive increases and the models become better at recognizing these patterns. Discounting external factors, such as governmental controls, it’s quite possible that symmetry is achieved and the question becomes one of human nature. In essence a question of how large the red team is compared to the blue. Security teams are famously understaffed. Has AI closed that gap for you, or has it just changed what the gap looks like? Staffing is always a contentious subject, and that’s unlikely to change, but I do not find that headcount is the answer to the AI-driven risks we’re seeing. Here at Gremlin, we processed just over 9 times the number of vulnerabilities over the last year as the previous, while maintaining the same staffing levels over the period. That certainly left a gap in our process. Using AI tools, largely LLM’s and supporting harnesses, we were able to handle that increase without additional headcount while simultaneously reducing our TTR by just over 5%. It was not trivial to achieve this throughput in the face of such a large increase in volume, and we had to react to it in a relatively short time. It took experienced human engineers to design the system to achieve that, leveraging what LLM’s provide to us, and to stay current as those systems evolve. But by embracing those same tools our adversaries were using, and investing in infrastructure around those tools, we have seen success thus far. Is AI changing what you look for when you hire security talent? What skill matters more now than it did five years ago, and what matters less? Yes, and I don’t think that will come as a surprise. Current AI systems are quite capable at producing on par with many entry level analysts and engineers, and more often than not only need an experienced operator to recognize confidently wrong outputs, and correct them. That takes a broad range of knowledge and experience with not just diverse technical systems, but the compliance and governance requirements driving many security programs. This raises the bar for all talent and creates a gap where it is increasingly difficult for new talent to gain the experience needed to operate these AI systems effectively. There is also an overarching concern of generational processing, and the potential for model collapse when the majority, or all, inputs into AI systems are themselves generated by AI systems. Similar to the need for genetic diversity in a population, LLMs need input diversity that today requires human curation. Currently we think of this as separate problems, a labor problem and a data problem. However, if we look historically, labor was how fresh inputs were provided to the systems, and we appear to be minimizing them at a time when we may need them most. What’s the most excited you’ve been about something in this space recently, something that isn’t just marketing language? I think the impact on application level security is exciting. It’s allowed us to move security concerns much earlier in the SDLC process by having AI evaluate against a curated list of criteria and policies, surfacing concerns and giving guidance in real-time as opposed to at some bottlenecked review period. This allows developers to propose and implement solutions with review from specialists, often avoiding the need for additional architecture and design requirements filtering back down the pipeline to developers. I no longer feel like I’m playing a catch-up game to stay current with changes. Many basic tasks that we previously depended on external development teams for are now internal side projects for my team because with some explicit review we know ‘the LLM can do this for us’, making a significant difference in our cadence.
helpnetsecurity.comSep 17, 2026extracted
A new open standard locks AI weights to approved hardware
A new open standard locks AI weights to approved hardware OPAQUE, a confidential computing company that runs AI workloads inside hardware-isolated environments so operators cannot inspect them, released an open standard that lets AI model builders decide when and where their weights can be decrypted once those weights leave the builder’s own servers. The standard, called Weight Custody Manifest, ships as a developer-preview specification, a Python SDK, and a public test suite covering 91 cases. The release targets a specific squeeze. Enterprises are fine-tuning open models on their own data, and AI labs are being asked to hand increasingly valuable frontier models to customers who insist the model run on infrastructure they control, including sovereign clouds kept within a country’s legal borders. Once weights leave the builder’s data center, the builder has no technical way to enforce what a contract says. WCM keeps weights encrypted until the receiving infrastructure proves, cryptographically, that it matches conditions the builder signed off on, and access can be pulled later if those conditions change. “Today’s Confidential AI protects the customer from the model. WCM protects the model from the customer,” said Imran Siddique, Chief Platform Officer at OPAQUE. “Builders need proof that their intellectual property will only be unlocked in an environment that meets agreed-upon conditions. WCM gives all parties verifiable proof instead of asking either side to simply trust the other.” How the check runs A protected workload requests a single-use challenge from a key broker. CPU and, where required, GPU attestation bind that challenge, a measurement of the running workload, and a transport key to the specific launch. The broker checks certificate chains, signatures, revocation status, and freshness before sealing the decryption key to that attested workload. A mismatch means no key. OPAQUE says it ran this exchange on an NVIDIA H100 and on separate AMD and Intel confidential servers hosted on Azure and Google Cloud, and that two independent builds of the SDK produced identical output across 5,948 files. What the demo does not prove Try the standard yourself and you get something different from what OPAQUE ran on its own hardware. The public quickstart runs broker and workload logic in one ordinary Python process, on synthetic evidence, with a placeholder key. Run the conformance suite and 91 checks pass, 32 at the first level, 37 at the second, 12 at the third, 10 at the fourth. All of it tests the reference protocol’s logic against synthetic certificate roots, and it skips GPU cryptographic verification entirely. A passing run confirms the code’s logic works as written. Confirming the hardware takes a separate test, run on the machine a builder plans to deploy. One limit here is sharp: a valid signature cannot tell an authorized key from one an attacker has already pulled out of the hardware. Physical attacks against confidential computing chips are real and documented, and OPAQUE points to that research instead of claiming the problem is solved.
helpnetsecurity.comSep 10, 2026extracted
UK Moves to Block High-Risk Tech Suppliers From Critical Infrastructure
The UK Cyber Security and Resilience Bill (CSRB) has been given late amendments specifically targeting the supply chain threat against the nation’s critical infrastructure. The UK CSRB – not to be confused with the US Cyber Safety Review Board (CSRB) – was introduced to Parliament in November 2025. It has successfully completed all necessary steps through the House of Commons, has moved to the House of Lords (as HL Bill 32) and is now close to receiving Royal Assent. Royal Assent is the point at which the Bill becomes an Act of Parliament and part of UK legislation, where it transitions into the Cyber Security and Resilience (Network and Information Systems) Act. At any time, both a bill and an act can be amended. An example has occurred recently. On August 22, 2026, The Telegraph newspaper reported that Iran-linked adversaries had targeted and forced a small-scale UK energy facility offline for four days. In itself, the attack had no serious effect but did raise questions over the potential effect of wider supply chain attacks on critical industry. The government reacted rapidly, and on August 24, 2026, tabled amendments to the CSRB underscoring an urgent need to give ministers powers to prevent (block) critical-sector organizations from using technology suppliers deemed high risk. “The confirmation that a UK energy generator was taken offline for four days following a cyber-attack, alongside government moves to widen the Cyber Security and Resilience Bill’s supply chain provisions, brings a long running policy debate into sharp focus. The incident involving the energy generator and the purported involvement of a nation state, has clearly sharpened appetite for the bill’s power to designate critical suppliers, regardless of sector or size,” comments Darren Guccione, CEO and co-founder at Keeper Security. “This Bill makes a critical distinction – that a hacker who can take a hospital offline, or compromise a water supply isn’t an IT problem, they’re a public safety threat,” adds Shankar Haridas, UK business head at ManageEngine. Jamie Akhtar, CEO and co-founder at CyberSmart, explains, “The proposed measures are another clear sign that supply chain security is becoming a national resilience issue, as well as a concern for individual businesses. Critical infrastructure organizations may have sophisticated security controls of their own, but their defenses can quickly be undermined if attackers are able to exploit a smaller, less well-protected supplier further down the chain.” The CSRB already contains stringent requirements, with very strict incident reporting timelines and heavy penalties for failure. Blocking individual companies takes it to a different level. “Attackers rarely go through the front door of a well-defended organization. The majority go through a vendor with lighter security, a managed service provider with standing access, or a supplier nobody has audited in years,” comments Guccione. Keeper’s own research shows that 34% of UK organizations report incidents involving third-party vendors or suppliers. It’s an interesting approach. Improve the security of the critical infrastructure not by demanding it implements better in-house security, but by disconnecting them from the third-party suppliers they consider to be inadequately secure. “Many SMEs won’t necessarily think of themselves as part of the UK’s critical infrastructure,” continues Akhtar, “but if they provide technology, services or access to organizations operating in critical sectors, their cyber resilience matters massively. Attackers understand this and will naturally look for the easiest route into their ultimate target.” He continues, “The Cyber Security and Resilience Bill reflects a wider shift towards greater accountability for third-party risk. Ultimately, the UK’s critical infrastructure is only as resilient as the organizations connected to it, and that means raising the baseline of cybersecurity across the entire supply chain,” concludes Akhtar. The supply chain threat is not new, but it continues to grow. The UK’s Cyber Security and Resilience Act will have teeth to force the weak point origin of supply chain attacks to make greater effort to ensure their own security. The target is the supply chain, but the bullseye is the SME origin. So, the message to SMEs serving the UK critical infrastructure is simple: improve your own cybersecurity lest your future profitability be affected by the UK government when the CSRB becomes the CSRA. Related: Rust Supply Chain Attack Linked to North Korean Hackers Related: Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack Related: Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack
securityweek.comSep 2, 2026extracted
153M+ driver’s licenses for sale on new dark web platform
A new dark web platform called Nexus claimed to be selling 153 million driver’s license scans and millions of other identity and medical cards. The collection included more than 153 million driver’s licenses, 10 million ID cards, 3 million travel documents, and 579,000 medical cards, including marijuana dispensary cards, according to reports . The trove of driver’s license scans reported by KrebsOnSecurity is a sharp reminder that identity verification is not a harmless box-ticking exercise. The FBI’s New Orleans field office has opened an investigation into an apparent breach involving identity verification provider IDScan.net. The company said it was investigating. IDScan.net advertises as follows: “We provide simple, secure solutions to help dispensaries reduce liability and protect their licenses by validating IDs, including a customer’s age, in a matter of seconds.” The allegedly exposed records were especially concerning because some included more than a basic photo of an ID. KrebsOnSecurity found records containing front-and-back images, as well as infrared and ultraviolet scans, with timestamps that appeared to align with the holders’ travel or car-rental activity. That matters because a driver’s license is far more useful to an identity thief than a password. You can reset a password. You cannot easily replace your face, date of birth, address, or license number, particularly when they’re accompanied by high-resolution images of your government-issued ID. The age-verification problem Age verification has become a common justification for asking people to upload an ID, take a selfie, or submit both to a third-party identity verification provider. We have previously warned about the privacy and security trade-offs in age-verification systems, particularly those that require people to submit copies of government-issued ID. Such systems can turn a request to access a website into a decision to share an enduring identity document with a company the user may never have heard of. In our opinion, that is a disproportionate risk. Once someone uploads an ID, the service or its vendor can potentially link the visit to their identity. If the provider is breached, the consequences can extend well beyond unwanted marketing or an exposed email address. The reported Nexus dataset illustrates a broader concern: Identity documents are collected in many places that people may not connect with one another. Each individual collection may be presented as routine, but together they create an ever-expanding ecosystem of organizations, contractors, software platforms, cloud services, and privacy policies. Facial images and ID copies can be reused. Criminals may use them to make scams more convincing, pass weak identity checks, or assemble detailed victim profiles from records obtained from separate breaches. An attacker who knows your name, address, date of birth, email address, and license details has a useful foundation for fraud. This is why “we only need to verify your age” should not automatically mean “please upload your driver’s license” or another form of ID. How to stay safe When an ID check is required to use an online service, ask a basic question: Why does this company need a copy of my identity document, and what happens to it afterward? The scale of the data reportedly offered through Nexus shows why the answer matters. Consumers cannot always refuse an ID check, particularly where it is legally required or necessary for a regulated service. But you can reduce unnecessary exposure: Ask whether an ID image is stored and, if so, for how long. Check whether the company uses a third-party identity verification provider. Prefer services that offer a privacy-preserving age check rather than requiring a full ID upload. Avoid submitting identity documents to sites you do not trust or did not intend to use. Do not email copies of IDs unless there is no safer alternative and you have independently verified the recipient. Be alert for phishing, account-recovery scams, and fraudulent credit applications if you believe your ID may have been exposed. Consider a credit freeze where available. Let’s face it, an incognito window can only do so much.     Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection  monitors for all of it, alerts you fast, and comes with identity theft insurance. 
malwarebytes.comSep 2, 2026extracted
CrowdStrike Extends Endpoint Security to Stop Software Supply Chain Attacks
Software supply chain attacks pose a critical enterprise threat. In the first half of 2026, these attacks increasingly used malicious software packages uploaded to public software registries, the CrowdStrike 2026 Threat Hunting Report found. Adversaries are poisoning open-source packages and exploiting the same dependencies that AI-assisted development tools and agentic applications pull onto enterprise endpoints every day. The endpoint is where those malicious packages land, execute, and need to be stopped. CrowdStrike is advancing endpoint security with Real-Time Supply Chain Attack Protection, a capability natively embedded in the lightweight CrowdStrike Falcon® sensor. It detects and blocks malicious open-source packages as they reach the endpoint, before any embedded code can execute, and provides a global inventory of installed packages across the organization. It requires no new sensor deployment, separate tool, or changes to developer workflows. The Problem Extends Beyond Developer Workstations When most organizations think about software supply chain risk, they think about developers running npm install or pip install on their workstations. That is a critical surface, but the picture has gotten much larger. In the AI era, everyone is a developer. Agentic applications like Claude Code and ChatGPT Codex are now used across marketing, HR, finance, and operations teams. These tools automate tasks, generate content, and build internal workflows. When an agentic application recommends downloading a package to complete a task, employees across the business may unknowingly expose their endpoints to compromised dependencies. The attack surface has expanded from a few hundred developer machines to potentially every company endpoint. Adversaries are capitalizing on this expanded surface, as documented in the CrowdStrike 2026 Threat Hunting Report: STARDUST CHOLLIMA poisoned 131 AI framework packages, which are trusted building blocks that can inherit access to sensitive enterprise assets and become attack paths for credential theft and persistence. ALTERED SPIDER compromised more than 300 software dependencies in a single day, spreading poisoned packages at scale and turning trusted code into downstream supply chain compromise.1 How Real-Time Supply Chain Attack Protection Works Real-Time Supply Chain Attack Protection extends the Falcon sensor’s visibility and control to non-executable software packages. When a package manager transaction is initiated, the Falcon sensor intercepts the download and evaluates suspicious files against CrowdStrike Falcon® Adversary Intelligence. If a match is found, the sensor immediately quarantines the file before any embedded setup script can execute. This is modern endpoint security doing what endpoint security does best: seeing and stopping threats where they land. The same unified sensor, already deployed, already protecting the fleet, now covers packages too, whether they’re downloaded by a human or an AI agent. Key capabilities include: Continuously monitor package activity: The Falcon sensor maintains a constant watch over package downloads across npm and PyPI on Windows, macOS, and Linux, closing critical entry-point blind spots and giving security teams visibility into active, incoming code across the enterprise fleet. Stop malicious packages at download: The Falcon sensor automatically detects and quarantines compromised packages the moment they are written to disk, neutralizing threats before malicious embedded scripts have a chance to execute. This is real-time prevention, not after-the-fact detection that requires a separate response workflow to contain damage. Automate fleet-wide investigation: The moment a new package is flagged as compromised, the Falcon platform instantly runs an intelligent lookback query across enterprise data. If a historical match is discovered, automated containment workflows isolate the threat and remediate affected endpoints, minimizing manual analyst triage. Gain full visibility with global package inventory: Falcon provides comprehensive visibility into software packages installed across the enterprise fleet, helping security teams understand package relationships and identify where risky versions reside, directly from the unified Falcon console. Implement proactive policy controls and cooldown protection: Falcon reduces software supply chain risk with granular, risk-based controls including minimum package age requirements, restrictions on publicly available packages, and automated fallbacks to approved versions. Security teams gain proactive governance over what code reaches their endpoints. Watch how it works: Proactive Protection: Control and Cooldown Beyond real-time detection and prevention, CrowdStrike is delivering granular policy controls that address a well-documented pattern: The first few days after a new package version is released represent a critical risk window, before malicious versions are widely identified and removed. Freshly published packages carry the highest risk because they have undergone the least community scrutiny. Proactive policy controls allow security teams to enforce minimum package age requirements before a package can be installed on a protected endpoint, effectively placing new and untrusted packages in a cooldown period. Organizations can also restrict access to publicly available packages or redirect users to approved, vetted versions. This gives security teams governance over what code reaches their endpoints while preserving productivity. Proactive policy controls are set to be released in Q4. Global Package Inventory Visibility is a prerequisite for control. Real-Time Supply Chain Attack Protection provides a comprehensive global inventory of installed software packages across the enterprise via CrowdStrike Falcon® Exposure Management, enriched with CrowdStrike Counter Adversary Operations intelligence. Security teams can understand package relationships, identify where risky package versions reside across the fleet, and take action from the same unified console they already use for endpoint protection. This inventory spans the entire managed fleet, covering every endpoint where packages are present, including the non-developer machines that developer-only solutions cannot see. Global Package Inventory is set to be released in Q3. Unified Through the Falcon Platform Real-Time Supply Chain Attack Protection ships through the existing Falcon sensor. There is nothing additional to deploy, no developer workflow to change, and no separate console to manage. Organizations that already run the Falcon sensor gain supply chain protection by enabling a policy. Our single-sensor architecture stands in sharp contrast to the alternative: deploying a separate developer workstation sensor from one vendor, a supply chain scanner from another, and still having no coverage for the majority of endpoints where agentic applications are actively downloading packages. The Falcon sensor already protects the fleet. Real-Time Supply Chain Attack Protection extends that protection to the package layer for every endpoint, with real-time blocking and automated remediation built in from Day One. As adversaries continue to weaponize the software supply chain at scale, defenders need real-time enforcement at the point of impact. Real-Time Supply Chain Attack Protection puts that enforcement exactly where it belongs: at the endpoint, at the moment of download, before code executes. Additional Resources Learn more about stopping supply chain attacks with CrowdStrike. See Real-Time Supply Chain Attack Protection in action. Read the CrowdStrike 2026 Threat Hunting Report to learn more about recent supply chain threats and adversary tradecraft. Disclaimer This blog includes discussion of unreleased services or features. Any unreleased services or features referenced here are still in development and subject to change. Customers should make their purchase decisions based upon features that are currently available. 1 CrowdStrike 2026 Threat Hunting Report
crowdstrike.comSep 2, 2026extracted
Next.js Patches Critical AVIF and Windows Flaws Enabling Unauthenticated RCE
Vercel has released security patches for two critical-severity vulnerabilities in the Next.js web framework, both of which allow unauthenticated remote code execution, one exploitable via specially crafted AVIF image files and the other through a path traversal flaw affecting servers that use a Windows filesystem. The Windows path traversal, tracked as CVE-2026-75604 (CVSS score: 9.0), affects Next.js applications that use both the Pages Router and App Router without Cache Components when the server uses a Windows filesystem. Linux and macOS deployments are not affected. "There is no known workaround for affected windows-hosted applications. You should upgrade immediately if your server is hosted on Windows," Vercel said in its advisory. The fixes are available in Next.js 15.5.24 (Maintenance LTS) and 16.3.3 (Active LTS), published on August 25, 2026. Affected users can upgrade by running npm install [email protected] for the 15.5 line or npm install [email protected] for the 16.3 line. Applications hosted on Vercel are protected from both vulnerabilities and require no upgrade, Vercel said in a changelog entry published August 25. The vulnerability affects Next.js versions 13.4 through 15.5.23 and versions 16.0 through 16.3.2. The attack mechanism was not disclosed in the advisory. Vercel's changelog also credited the researchers evolutionstorm and B0RI with the responsible disclosure of the Windows vulnerability. AVIF Image Optimization Flaw Next.js uses the sharp image processing package to optimize images, and sharp relies on the libheif C library to parse AVIF files. A critical heap buffer overflow in libheif can lead to remote code execution when Next.js processes an attacker-controlled AVIF image (GHSA-2xp9-vwfh-vxw4, CVSS v4: 9.5). The underlying vulnerability, disclosed by the libheif maintainers as GHSA-g89c-p67h-r497, involves a heap buffer overflow in the library's image scaling code. All libheif versions through v1.23.1 are affected. The AVIF advisory covers Next.js versions 10.0.0 through 15.5.23 and all 16.x releases through 16.3.2. A crafted AVIF file that contains nested identity-derivation and auxiliary item references causes libheif to build a decoded image with two Alpha plane entries at different bit depths. The scaler allocates a destination buffer sized for the first, 8-bit Alpha entry but then writes 16-bit sample values from the second entry into that same buffer, overwriting approximately 16,384 bytes past the allocation boundary. The researchers credited in the advisory, rootxharsh as Finder and KarimPwnz as Coordinator, released a full Python proof-of-concept alongside the libheif disclosure that reproduces the heap corruption under an address sanitizer build. The libheif advisory credited rootxharsh as Finder and KarimPwnz as Coordinator, but Vercel's changelog attributed the disclosure to the Hacktron team. "We were able to get RCE using this on multiple applications," the researchers said in the libheif advisory. The proof-of-concept demonstrates the out-of-bounds write, and the researchers' claim of remote code execution on multiple applications has not been independently corroborated. Next.js enables AVIF optimization only when a site explicitly adds image/avif to the formats configuration in next.config.js. Deployments without that configuration are not exposed to this flaw. The patched Next.js releases turn off AVIF optimization entirely until the upstream fix propagates from libheif. The Hacker News confirmed on August 27, 2026, via the libheif GitHub releases page that v1.23.2 had not been published. Vercel had scheduled the August patches for August 26 as part of its monthly security cadence, but moved the release forward by one day after discovering an additional critical-severity vulnerability in one of its upstream dependencies. "Earlier today, we moved the release forward after identifying an additional critical severity vulnerability in one of our upstream dependencies," Josh Story, Karim Rahal, and Sebastian Silbermann said in Vercel's security blog post. The August release is the second under Vercel's formal monthly security program, which the company announced in July 2026. "The volume of vulnerability research across the industry is rising fast, driven by LLM-assisted discovery," Andrew Imm and Josh Story said in the July 13 program announcement. The first scheduled release, published on July 21, addressed nine vulnerabilities in Next.js 16.2.11 and 15.5.21, covering denial-of-service, server-side request forgery, and middleware bypass classes. Users already on those July patches still need the August upgrade. Next.js has seen a run of critical security disclosures over the past two years, including a critical middleware bypass flaw in March 2025 that allowed unauthenticated attackers to skip authorization checks in self-hosted deployments. The React2Shell deserialization flaw in React Server Components, disclosed in December 2025, carried a CVSS score of 10.0 and was actively exploited within hours of public disclosure. No exploitation of either August vulnerability had been reported as of August 27, 2026. The Hacker News reached out to Vercel for comment and had not received a response by the time of publication.
thehackernews.comAug 27, 2026extracted
Benchmaxxing: When the Benchmark Becomes the Target
Public benchmarks in AI provide important signals and allow for regression testing, directional validation of model updates, and public discussion of capabilities and limitations. But the more attention a benchmark receives, the stronger the incentive to optimize for it. Once a score becomes the goal, teams start benchmaxxing: optimizing for the benchmark rather than the capability it is meant to measure. This is a familiar problem in the AI space. As Goodhart’s Law suggests, measures become less useful when they become targets. Gaming, ceiling effects, and data leakage erode the signaling value of doing well on public benchmarks. In the AI and cybersecurity space, the problem carries greater consequences because benchmark results can shape real security decisions. The industry has seen this before. Last decade, we called it "detection coverage" and learned through experience that vendors passing canned tests was a poor proxy for stopping adaptive adversaries in real environments. As AI becomes more deeply embedded in cybersecurity, we should not repeat the same mistake with a new class of benchmarks. In this blog, we examine the limitations of public cyber benchmarks and describe an approach for task-coupled internal benchmarks that drive rigorous science rather than optimizing for visibility or attention. The Challenges of Cyber Benchmarking The headlining failure of most cyber-relevant AI benchmarks is that they fail to measure what matters most: the ability of defensive cyber agents to reason end-to-end across exploits, telemetry, and environments, and generate novel detection or remediation strategies. In short, benchmarks fail to measure the ability to stop breaches. Benchmarks typically need ground truth for scoring, making them retrospective and often binary. This does not reflect defenders’ real challenges, which are constantly novel and epistemically gray. Benchmarks also rarely report the harms caused by mistakes, while leaderboards commonly downplay costs and times. Those factors are critical, especially as, for instance, eCrime breakout times are plummeting. By comparison, the reference action, human red teaming and detection generation, is well understood. Overall scores often obfuscate subpopulations where solvers perform poorly. A scoreboard might show 97%, but if that 3% falls within a group of jointly exploitable attack paths, the aggregate score has little construct validity. While benchmarks can be useful regression tests, their headlining results are structurally biased against generalizing to the real world. Contamination from direct or indirect leakage, solution leakage, and retrospective tasks all lower the upper bound on generalization. When the same model and harness are shipped, they will almost certainly underperform on novel stimuli. Overfitting, an inevitable result of benchmaxxing pressure, can also occur due to repeated evaluation. Every development cycle that checks the public test set and adjusts accordingly leaks information into the model, even with zero gradient updates. More subtly, publication bias causes the error distribution to be skewed strongly downward, as published results are likely drawn from surprisingly strong runs that are unlikely to be repeated. Common reporting patterns compound this problem by downplaying the probabilistic nature of results from agentic workflows. “Solved it in at least one of ten attempts” with an unbounded budget is grade inflation, not rigor. While these issues may seem esoteric or statistical, there are also more basic issues with benchmark scores because of the extent to which agents cheat. Dreadnode reported last month that more than a third of all passes on individual tasks on Cybench, across nearly every model assessed, involved cheating. In these cases, models searched postmortems on attacks, probed evaluation infrastructure, and read or inferred answers or paths from evaluation container metadata. When cheating is this prolific, benchmarks are not only measuring the wrong thing, they are doing so poorly. Public cyber benchmarks can also create information that benefits adversaries. Leakage, and even test questions themselves, can be used for model training or uplift. The public nature of benchmarks may also help adversaries understand which existing vulnerabilities are considered important enough to measure, and how detectable they are. Advanced adversaries may reason about vulnerabilities that are not measured and treat those gaps as potential soft spots. How CrowdStrike Approaches Benchmarks and Evaluations At CrowdStrike, rigorous evaluations are core to guiding our fast-moving AI research and development agenda. Substantively, our evaluations are designed to directly measure the capabilities we care about across malware analysis, detection engineering, threat intelligence comprehension and synthesis, log and telemetry analysis, and incident response reasoning. They measure real outputs against live problems, with increased realism driven by high-quality digital twins of real-world customer environments and increased difficulty driven by adversary tradecraft emulation. Being exceptionally difficult is a hallmark of our evaluations. Evaluations and benchmarks at CrowdStrike are intended to be living methods, not static checks. Public benchmarks provide useful common reference points, but for organizations deploying frontier AI, the most meaningful measures of success are private evaluations grounded in their own data, systems, workflows, and operational outcomes. These evaluations test whether an AI system can perform reliably where it will actually be used, not simply whether it can score well on a widely known test. Instead of optimizing for success in loosely related tasks, CrowdStrike’s benchmarks are task-coupled to support sharp decision-making. We are applying this approach in practice today. Our teams introduce novel evaluation content, rotate validation sets, and assess capabilities against cybersecurity problems that reflect real operational conditions. This helps preserve benchmarks as useful mileposts while creating more relevant tests that evolve with the systems being evaluated and reduce opportunities for benchmaxxing. We also separate evaluation developers from our solution architects. This firewalling helps limit leakage and preserve the credibility of evaluations over time. Our deployment methodology supports many-time/any-time runs at scale, allowing us to measure the full error distribution of solvers and report them meaningfully. Further, our measurement scheme goes well beyond task completion to include other factors that matter in the real defensive world, including cost, latency, stealth, and completeness. Public benchmarking still has an important role when it advances shared industry understanding. In partnership with Meta, CrowdStrike introduced CyberSOCEval, an open-source benchmark suite designed around real-world SOC workflows, adversary tradecraft, and operational outcomes. Ultimately, the goal is not to produce the highest benchmark score, but to build evaluations that tell us whether AI systems can deliver reliable defensive outcomes against the complexity and uncertainty of real-world cyber threats. Additional Resources Learn how CrowdStrike Falcon® AI Detection and Response secures AI. Download our guide to explore the five steps for frontier AI security readiness. Explore cutting-edge cybersecurity research at Day Zero 2026, a summit for the threat research community. Experience Fal.Con 2026 from anywhere with Fal.Con Digital, featuring keynote livestreams and on-demand access to 100+ sessions.
crowdstrike.comAug 19, 2026extracted
DDoS attacks hit record scale as 1 Tbps+ campaigns become more common
DDoS attacks hit record scale as 1 Tbps+ campaigns become more common DDoS attacks grew in scale during the first half of 2026, bringing larger traffic floods, shorter attack durations, and increasingly automated campaigns. Cloudflare’s H1 2026 DDoS Threat Report shows threat actors relying on multi-vector techniques and large-scale network-layer attacks to disrupt online services across multiple industries. L3/4 attack-size distribution (bitrate), H1 2026 (Source: Cloudflare) Network-layer attacks remained a primary driver of activity as hyper-volumetric campaigns capable of generating traffic measured in terabits per second became more common. Cloudflare reported a significant increase in attacks exceeding 1 Tbps, showing the growing prevalence of extremely high-bandwidth campaigns. “April 2026 was a peak month for DDoS activity and volume, hitting a high of 6.46 trillion requests and 165 petabytes (PB) respectively,” the company said. “Despite the hyper-volumetric growth, the median DDoS attack Cloudflare mitigated in the first half of 2026 remained short and small with 96.62% of network-layer attacks remaining under 500 Mbps and 90.60% ending in under 10 minutes.” Application-layer attacks remain a major threat Application-layer attacks continued to target websites, APIs, and online services using HTTP flood techniques. Cloudflare reported that attackers increasingly combined HTTP floods with network-layer attacks as part of multi-vector campaigns, allowing them to shift attack methods during an incident and complicate mitigation efforts. Threat actors combined network- and application-layer attacks within the same campaign, shifting attack vectors throughout an incident to increase pressure on defensive systems. By targeting multiple layers simultaneously, attackers can complicate mitigation efforts and increase the likelihood of service disruptions. DDoS-for-hire platforms, compromised Internet of Things (IoT) devices, and automated attack tools continue to lower the barrier to launching large-scale attacks. These resources allow threat actors to generate significant traffic volumes without building or maintaining their own attack infrastructure. Critical sectors remain under pressure Government organizations experienced a sharp increase in HTTP DDoS attacks during the second quarter of 2026. Cloudflare observed the surge following Operation Epic Fury, a period during which security researchers recorded 149 hacktivist DDoS claims targeting 110 organizations across 16 countries within 72 hours. Of the targeted organizations, 47.8% belonged to the government sector. The media, production & publishing sector ranked as the most targeted industry during both quarters of the first half of 2026, accounting for 14.2% of all mitigated HTTP DDoS requests—nearly four times the share of the second-ranked industry. Attackers continued to launch short-duration, high-intensity campaigns. Many attacks lasted less than one minute, leaving security teams with little opportunity to respond manually before mitigation was required and demonstrating the value of continuous monitoring and automated defenses China ranked as the most targeted location accounting for 22.4% of all mitigated HTTP DDoS requests in the second quarter. The United States followed with 18.8%, while Turkey climbed to third after more than doubling its share of global attack traffic. Cloudflare noted that Turkey’s increase coincided with preparations for the 2026 Ankara NATO Summit, during which Turkish authorities conducted large-scale pre-summit security operations. Brazil overtook the United States as the leading source country for DDoS attacks during the reporting period, accounting for 14.9% of mitigated DDoS request traffic compared with 13.4% for the United States. The shift was driven by a sharp increase in the second quarter, when Brazil generated 21.4% of all mitigated DDoS request traffic. Indonesia retained its position as the third-largest source country for DDoS attacks. DNS floods dominate network-layer attacks DNS-based attacks remained the most common network-layer attack vector. DNS Flood and DNS Amplification attacks accounted for 34.3% of all network-layer attacks, making them the leading techniques used to disrupt online services. CLDAP Flood attacks increased 580% quarter over quarter, making the technique the third most common network-layer attack vector during the second quarter of 2026. CLDAP attacks abuse exposed LDAP-over-UDP services to amplify traffic and overwhelm targeted systems.
helpnetsecurity.comAug 13, 2026extracted
Black Hat USA 2026 – Summary of Vendor Announcements (Part 2)
Many companies are showcasing their cybersecurity products and services this week at the 2026 edition of the Black Hat conference in Las Vegas. To help cut through the clutter, the SecurityWeek team is publishing a digest summarizing vendor announcements at Black Hat USA 2026, including new products and services, updates to existing offerings, reports, and other initiatives. The first part of this roundup was published on August 3. Astelia unveils agentic AI exposure management capabilities Astelia launched its new agentic AI capabilities for its exposure management platform, automating reachability analysis and remediation workflows across the entire vulnerability lifecycle. By adding this new agentic layer, the platform now evaluates newly disclosed vulnerabilities and their reachability, assesses operational impact, coordinates remediation across security and IT teams, and helps drive each issue toward resolution. Human approval remains built into key decision points, with every action logged and auditable. AvePoint adds continuous data sensitivity classification to Confidence Platform AvePoint has introduced Kinetic Classification, a capability that continuously re-evaluates data sensitivity across Microsoft 365, Google Workspace, and other business applications, replacing static, one-time labeling. AvePoint also added new tools to its Rapid Recovery system, including a Rapid Recovery Wizard and Express Recovery for Entra ID, meant to help teams prioritize restoration of critical data after an incident. CrowdStrike publishes 2026 Threat Hunting Report CrowdStrike’s 2026 Threat Hunting Report finds that AI is now embedded across modern adversary operations, with threat actors using AI to accelerate attacks, exploit vulnerabilities within hours of public disclosure, and target enterprise AI systems and software supply chains. The report also highlights a sharp rise in cloud-focused attacks, AI supply chain compromises, and abuse of trusted authentication workflows, underscoring the need for organizations to secure AI environments while using AI to defend against increasingly automated threats. Cisco Talos research shows how threat actors are weaponizing AI Cisco Talos released new research detailing how threat actors are using AI and LLMs in real-world cyberattacks. Drawing on recovered prompt logs, attack tooling and threat actor conversations, the research documents how AI is being used to develop malicious code, build fraud infrastructure, and accelerate vulnerability research and exploitation. The research found that threat actors rarely need sophisticated jailbreaks; sophisticated threat groups are leveraging AI as a development assistant to rapidly build exploits; and that adversaries use AI across various steps of the attack lifecycle and operations. Drata extends trust management platform to AI agents Drata has extended its Trust Management Platform, announcing the limited availability of AI Agent Governance, which is designed to help enterprises discover, monitor, govern, and prove traceability of the AI agents running inside the organization. The product ships first for Anthropic, with early access customers already running it end-to-end in production. Horizon3 extends production-safe autonomous pentesting to web applications Horizon3.ai announced NodeZero WebApp Pentesting, an expansion that enables the NodeZero platform to autonomously and safely test web applications the way attackers operate. It proves what is actually exploitable, quantifies the business consequence of each attack path, and maps those paths to the tactics of known threat actors. The announcement comes just as the company raised $250 million in funding. Huntress expands Managed ESPM with free RMM Guard Huntress announced that its RMM Guard is now available for free to all customers with an agent deployed, as part of its broader Managed ESPM effort. This release is focused on detecting and blocking rogue remote monitoring and management tools that attackers increasingly abuse to gain and maintain access. RMM Guard identifies and blocks unauthorized RMM software on endpoints before it can be used for persistence or remote control, lets teams define which RMM tools are approved and which should be blocked, and adds extra protection for isolated machines so approved remote access tools do not get blanket access. The announcement comes in light of a new N-central RMM vulnerability being exploited in the wild. Legit Security releases VibeGuard 2.0 for coding agent endpoint security Legit Security has released VibeGuard 2.0, an endpoint-based tool that discovers and secures AI coding agents such as Claude Code, Cursor, and GitHub Copilot. It operates at the endpoint level, applying policy enforcement and granular controls over specific agent commands and tools. New features include guardrails for skill discovery, blocking of risky operations, MCP security controls, command monitoring against built-in or custom policies, and anti-tampering protections meant to stop agents or users from disabling the tool. Netskope announces DataSec Command Center Netskope announced its Netskope One DataSec Command Center, a unified control plane that discovers, understands, tracks, and protects sensitive data of any kind wherever it lives and moves, from AI environments to the network. With Netskope One DataSec Command Center, security teams gain full visibility into their sensitive data and a seamless path from discovery to remediation across their entire data landscape. ProjectDiscovery announces general availability of Neo ProjectDiscovery announced the general availability of Neo v1, and a new Pay-as-you-go model. After six months of private beta testing with enterprise customers, ProjectDiscovery is making Neo available to everyone to help teams move from periodic, manual testing toward continuous security that runs alongside development. Teams of all sizes can access autonomous security testing across code, applications, APIs, cloud and networks with this new pay-as-you-go model, without traditional procurement and budget barriers. Qualys adds scanless vulnerability detection to ETM platform Qualys has introduced InstaScan, a scanless detection capability inside its Enterprise TruRisk Management (ETM) platform. The feature is powered by Agent Insta, an AI agent that continuously matches newly published vendor advisories against an organization’s existing asset inventory and telemetry rather than relying on scheduled scans. It normalizes software identities into standard identifiers (such as CPEs and PURLs) to build a consolidated inventory, then flags affected assets and issues confidence-scored findings. SailPoint unveils SailPoint Identity Security SailPoint has unveiled SailPoint Identity Security, a combination of SailPoint Agentic Fabric and SailPoint Human Fabric designed to deliver a continuous, real-time loop to discover, govern, and protect digital environments across human, non-human and agentic identities. Sectigo launches automation gateway for certificate lifecycle management Sectigo has released Sectigo Orchestration Gateway (SOG), a new automation layer inside its Sectigo Certificate Manager (SCM) platform. The gateway lets IT teams automate certificate discovery, issuance, renewal, and deployment across servers, load balancers, CDNs, WAFs, and access systems from a single install. It includes native support for platforms such as IIS, Apache, F5, NGINX, and Citrix, along with direct integrations with credential managers CyberArk, Delinea, HashiCorp, and BeyondTrust for just-in-time credential retrieval. Sevii expands ADR platform with autonomous preemptive security module Sevii announced a major expansion of the Sevii Autonomous Defense & Remediation (ADR) platform with the general availability of an Autonomous Preemptive Security (APS) module. The new module extends the platform to continuously transform external global and internal environmental cyber intelligence into autonomous hypothesis hunting, exposure validation, compromise detection, and autonomous remediation. Sysdig launches AI-native offering for cloud runtime defense Sysdig has launched Sysdig Secure AI, an AI-native addition to its Sysdig Secure cloud-native application protection platform (CNAPP). The offering provides three ways to apply AI to cloud defense: autonomous agents that prioritize risks and issue remediations, a “headless” mode that integrates with AI coding agents such as Claude, Cursor, and Codex, and a GenAI assistant (formerly Sysdig Sage) that explains risks and recommends fixes in plain language. Tanium expands Autonomous IT Platform with new agentic and exposure tools Tanium added new capabilities across its Autonomous IT Platform in three areas. Tanium Atlas now includes Agentic Performance Analysis for root-cause tracing, Background AI Agents that run alert-to-resolution workflows autonomously, and an MCP Server that exposes Tanium data to clients like Claude and Microsoft Security Copilot. New exposure management tools add External Attack Surface Management and Attack Path Mapping, while a new Agent-Guided Threat Hunting feature runs hypothesis-driven hunts mapped to MITRE ATT&CK, paired with a private-preview integration with Google Threat Intelligence. Torq unveils SOC Brain Torq has introduced Torq SOC Brain, a new self-learning layer of its AI SOC Platform that continuously learns from historical investigations, analyst decisions, and organization-specific security operations to create a personalized intelligence engine. By utilizing its Recall, Reflex, and Retrospect capabilities, the system reasons from precedent and organizational history to adapt to each team’s unique risk logic and deliver increasingly accurate threat classifications over time. Viakoo adds configuration drift remediation module for OT and IoT devices Viakoo has introduced Device Configuration Manager (DXM), a new module for its Viakoo Action Platform aimed at correcting configuration drift in OT and IoT environments. The agentless tool continuously audits device settings against defined baselines, flags unauthorized changes, and automatically restores devices to a compliant state. Viakoo also expanded its integrations to include Armis, Forescout, Nozomi Networks, Claroty, and Tenable. DXM is expected to become available in Q4 2026. Vicarius publishes state of vulnerability remediation report Vicarius released its “Exposed and Unfixed: The 2026 State of Vulnerability Remediation” report, which shows that siloed workflows and manual administrative handoffs leave 79% of organizations vulnerable to known exploits they already knew about. The report data found that 75% of critical vulnerability responses simply trigger an administrative workflow rather than actually resolving the threat, 50% of organizations consider a vulnerability “closed” based on pure risk acceptance or ticket generation rather than running a verified rescan to ensure the patch worked, and 79% of organizations experienced a security incident in the past 12 months involving a vulnerability that was already sitting in their inventory. Zimperium releases automated mobile forensic investigation tool Zimperium has introduced Deep Insights, a mobile forensic investigation tool built to automate analysis of mobile device attacks. The tool reconstructs full attack timelines from collected evidence, allowing tier-one SOC analysts to investigate incidents without specialized mobile forensics expertise. It also runs automated pre- and post-travel comparisons to flag suspicious changes in device state. Deep Insights is expected to become generally available in September 2026.
securityweek.comAug 4, 2026extracted
178: Ubiquiti
Nickolas Sharp worked for Ubiquiti, a company that makes networking equipment. He noticed that there were some security problems at work. He tried to point them out, but didn't feel like he was being listened to enough. What do you do when the company you work for isn't securing their software up to your standards? Well, he thought he needed to teach them a lesson, but in the end, he learned an even bigger lesson. Sponsors This show is brought to you by Drata . Drata is the trust management platform that uses AI-driven automation to modernize governance, risk, and compliance, helping thousands of businesses stay audit-ready and scale securely. Learn more at drata.com/darknetdiaries . This show is sponsored by Material Security . Your cloud office (think Google Workspace or Microsoft 365) is the core of your business, but it’s often protected by scattered tools and manual fixes. Material is a purpose-built detection and response platform that closes the gaps those point solutions leave behind. From email threats to misconfigurations and account takeovers, Material monitors everything and steps in with real-time fixes to keep your data flowing where it should. Learn more at https://material.security . Support for this show comes from ThreatLocker . ThreatLocker is a Zero Trust Platform that gives organizations control over what can run and what users and devices can access. It combines prevention with real time detection and automated response, helping security teams stop unauthorized activity and quickly contain compromised machines. Learn how ThreatLocker can strengthen your defenses at threatlocker.com/Darknet . View all active sponsors. Sources Full list of sources on the show page: https://darknetdiaries.com/episode/178/
darknetdiaries.comAug 4, 2026extracted
Google says AI helped Chrome fix 1,072 security bugs in two releases
Google says artificial intelligence is dramatically increasing the number of security vulnerabilities it can find and fix in Chrome, with more than 1,000 security bugs patched across the browser's two most recent releases as it expands its use of AI. According to Google, Chrome 149 and Chrome 150 fixed 1,072 security bugs, surpassing the total number fixed across the previous 23 Chrome milestones combined. The company says it now uses large language models throughout the vulnerability management process, including discovering flaws, reproducing reports, determining severity, assigning bugs to developers, generating candidate patches, and creating tests. Google began using LLMs to improve security fuzzing in 2023 before working with Project Zero on Naptime, a system that provided AI models with specialized vulnerability research tools. The company later collaborated with Google DeepMind and Project Zero on Big Sleep, an AI-powered vulnerability discovery agent that found flaws in Chrome’s V8 JavaScript engine and graphics components. In early 2026, Google created a Gemini-powered agent harness to search the broader Chrome codebase for vulnerabilities while reducing false positives. One vulnerability discovered by the system was a Chrome sandbox escape that had remained in the codebase for more than 13 years. If exploited, the flaw would have allowed a compromised renderer to escape the sandbox and trick the browser into reading local files. Google is also encouraging its developers to add SECURITY.md files describing trust boundaries and threat models, helping its AI systems better identify operations with security implications. The company says its multi-agent AI workflows help rather than replace existing security testing, including fuzzing, which remains effective at discovering complex vulnerabilities. Google has also seen a sharp increase in reports submitted through the Chrome Vulnerability Reward Program, and by March 2026, the company had received more security bug reports than during all of 2025. This prompted Google to modify its program to prioritize reports that add to what its already finding and processing through its automated tooling. The company is also automating vulnerability triage, including filtering spam and duplicates, reproducing proof-of-concept exploits, assigning severity ratings, and routing reports to the appropriate developers. Google estimates that this automated process saves hundreds of hours of developer time each month. After a vulnerability is confirmed, fixing agents generate multiple potential patches, while another agent evaluates the proposed fixes and produces additional information for developers to review. In May, these systems reportedly prevented more than 20 vulnerabilities from reaching production, including one issue classified as critical. However, Google says finding and fixing vulnerabilities more quickly also requires accelerating how patches are delivered to users. Once a security fix is committed to Chrome’s public source code, attackers can inspect the change and attempt to reverse-engineer the vulnerability before the update reaches users. Google is also transitioning Chrome to a two-week major release cycle with weekly security updates and is piloting two security releases per week to reduce this patch gap. To reduce disruptions, the company is developing "dynamic patching," which would allow Chrome to apply updates without restarting the browser. Starting with Chrome 150 on macOS, the browser can automatically restart to apply a pending update when it is running in the background without any open windows. Google says its long-term goal is to keep Chrome continuously updated through dynamic patching, automatic restarts during periods of inactivity, and improved session restoration. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comJul 30, 2026extracted
These near-mint ASUS Chromebook refurbs are only $145
Buying a new computer in 2026 is a unique experience. Rather than deal with incredibly high tech prices, more shoppers are opting for high-quality refurbished tech. This ASUS Chromebook CM30 refurb is in near-mint condition with a grade “A” rating, but it still only costs $144.97 (reg. $369.99) on sale. A tablet and a laptop for under $200 This is a Grade “A” refurbished Chromebook, so it arrives in near-mint shape with minimal to no scuffing on the case. The screen is a 10.5-inch WUXGA touchscreen at 1920×1200, and it hits 400 nits with 118% sRGB coverage, so text stays sharp, and colors hold up in a bright room. Inside, there’s a MediaTek Kompanio 520 with 8GB of RAM. Storage is a 128GB eMMC drive. That combination handles Chrome OS, a stack of browser tabs, and streaming without stalling. It’s a great machine for lightweight tasks and portability, but that’s not all it can do. The detachable keyboard and magnetic stand cover let you drop the screen off and use it as a tablet in seconds. A push-pop stylus charges fast and stores right in the body, so you’re not hunting for it or leaving it behind on accident. Dual 5MP cameras cover video calls and quick captures. The chassis is military-grade aluminum made with 30% recycled material, and it meets MIL-STD 810H durability standards. Battery life runs up to 12 hours, so a full workday or a long flight won’t leave you chasing an outlet. Wi-Fi 6 and Bluetooth 5.3 keep connections quick, and you get a USB-C port plus a headphone jack. A 90-day parts and labor warranty from a third party is included. Get a 2-in-1 computer that works on the couch and at the desk without paying new-hardware prices. Until August 9 at 11:59 p.m. PT, get a grade “A” refurbished ASUS Chromebook CM30 on sale for $144.97. Prices subject to change. Disclosure: This is a StackCommerce deal in partnership with BleepingComputer.com. In order to participate in this deal or giveaway you are required to register an account in our StackCommerce store. To learn more about how StackCommerce handles your registration information please see the StackCommerce Privacy Policy. Furthermore, BleepingComputer.com earns a commission for every sale made through StackCommerce. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comJul 29, 2026extracted
Cloudflare reveals what’s behind major internet outages
Cloudflare reveals what’s behind major internet outages Storms, earthquakes, and infrastructure failures disrupted internet access throughout the second quarter, while governments deliberately shut networks down, according to Cloudflare’s latest Internet Disruption Summary. Based on Cloudflare Radar traffic data, the report covers internet disruptions recorded between April and June 2026. Governments switching access on and off Iran began restoring nationwide internet access on May 26, ending an 88-day shutdown that began on February 28. Traffic hit 40% of pre-shutdown levels the next day. “Since then, we have seen HTTP bytes climb to as high as 90% before settling back to roughly 59% of pre-shutdown levels,” said Lai Yi Ohlsen, Senior Product Manager at Cloudflare. “This volume is consistent with the traffic we observed in February, a window between this recent shutdown and a previous one in January, suggesting that connectivity has returned to something like its most recent pre-shutdown baseline rather than fully normalizing.” Elsewhere in the region, damage to physical infrastructure in the United Arab Emirates and Bahrain has kept traffic to an AWS cloud region in the UAE low since March. AWS reported that drone strikes hit two facilities in the UAE, while another strike near a Bahrain facility caused physical damage. “The decreased traffic is the downstream signature of physical damage to the underlying data center infrastructure rather than a network fault, and it continues to affect the websites and applications hosted in that region, regardless of their own availability,” noted Ohlsen. Exam season brought its usual round of shutdowns. Iraq ordered three government-mandated blackouts, on June 2, 11, and 28, and Sudan ordered ten between April 13 and 23, all meant to stop students from cheating. Sudan’s outages ran about 3.5 hours each, timed to the exam window; Iraq’s lasted around 90 minutes. Broken cables and broken signatures On May 5, a routine cryptographic key rollover at DENIC, the registry for Germany’s .de domain, went wrong and started producing invalid DNSSEC signatures. Resolvers that check DNSSEC rejected every .de lookup for several hours, until the registry fixed the problem. Users saw pages fail to load and email bounce, the same symptoms as an outage, even though the network itself was working the entire time. “From a user’s perspective, the incident was experienced not as a DNS or cryptographic failure but simply as a wave of .de websites and services suddenly becoming unreachable. Though users were still able to access sites that did not use the .de TLD, the experience included pages failing to load, email bouncing, and apps timing out, all of which can mirror the experience of an outage,” Ohlsen added. In the Caribbean, a fiber cut near Saint Lucia took Karib Cable’s network to close to zero traffic on June 21. Service remained disrupted for nearly a day before recovering. Because Karib Cable is one of the island’s largest providers, the country’s overall traffic fell by about 60% compared with the previous week. Storms, quakes, and blackouts Super Typhoon Sinlaku, the strongest storm of the 2026 Pacific typhoon season so far, passed just north of Guam in mid-April. The island avoided a direct hit, but tropical-storm-force winds still took down power and water systems. Traffic from the territory dropped as much as 80% below expected levels on April 13 and 14. On June 24, two earthquakes struck northern Venezuela within about a minute of each other, near Yumare and San Felipe, followed by an aftershock off the coast near Caracas. The first quake measured magnitude 7.5. Cloudflare Radar recorded a sharp drop in HTTP traffic at the moment of the quakes, visible in Fibex Telecom, state-owned CANTV, and the smaller ISP VNET. Days later, a power outage in Tanzania on June 27 cut HTTP traffic there for at least five hours. Cloudflare notes that the telemetry looked almost identical to the deliberate, election-related shutdown Tanzania imposed in October 2025, even though this outage had a different cause. “It is striking how such fundamentally different events leave such similar footprints in the data and user experience. Taken together, these weather-related and power-driven disruptions demonstrate the immense impact the physical world can have on the digital, and the importance of Internet resilience and of building networks with enough redundancy in power, routing, and physical paths to withstand inevitable shocks,” concluded Ohlsen.
helpnetsecurity.comJul 29, 2026extracted
GitHub revamps bug bounty program with new VIP tier, payout changes
GitHub revamps bug bounty program with new VIP tier, payout changes GitHub is changing its bug bounty program to reward higher-quality vulnerability reports and reduce low-effort submissions, including AI-generated reports. The changes will take effect on July 27, 2026. Reports submitted before that date will be honored under the previous bounty structure. “Alongside the growth in legitimate reports, we’ve seen a sharp increase in submissions that don’t demonstrate real security impact. These include reports without a proof of concept, theoretical attack scenarios that don’t hold up under scrutiny, and findings already covered by our published ineligible list,” Jarom Brown, Senior Product Security Engineer, Bug Bounty at GitHub, explained. VIP program and payout changes GitHub is formalizing a permanent, private, invite-only VIP program for researchers who consistently deliver high-quality, high-impact findings. Participants will receive higher payouts, faster response times, and closer collaboration with GitHub’s engineering team. VIP program bounty table (Source: GitHub) The company said the eligibility criteria will be published on its public HackerOne page. To qualify, participants must meet at least one of the following thresholds: one critical finding, two high-severity findings, four medium-severity findings, or seven low-severity findings. Public bug bounty payouts are also being restructured. The new table assigns a single payout to each severity level to simplify expectations for researchers while allowing GitHub to award discretionary bonuses for exceptional submissions. “This adjustment will enable us to provide more tailored attention and higher rewards to our VIP program, while still enabling our public program to be a place to explore and serve as a feeder into the VIP program,” Catherine Cassell, Product Security Engineer at GitHub, said. New signal requirement for researchers GitHub is also introducing HackerOne’s signal requirement to reduce low-effort and AI-generated reports while keeping the program accessible to new researchers. Under the requirement, newcomers can make up to four initial submissions while they establish signal in the public program. Researchers who do not meet the signal threshold will have a limited number of allowed submissions until they establish a track record.
helpnetsecurity.comJul 23, 2026extracted
AI Can Find Bugs, But Human Knowledge Still Proves Them
Artificial intelligence (AI) is changing offensive security, but it has not changed the standard that matters most: a finding has to be proven before it becomes useful. AI-assisted tools can read code quickly, generate payloads, summarize attack surfaces, explain unfamiliar APIs, and run repetitive testing workflows at impressive speed. That is a real advantage for security teams. It also creates a new kind of pressure, because the industry can now produce more vulnerability-looking output than ever before. The problem is that output is not the same as evidence. A generated report can sound polished, include a severity rating, and even contain a proof-of-concept that looks reasonable at first glance. None of that proves the bug exists in the deployed environment. None of it proves exploitability, impact, or risk. In offensive testing, the hard part has never been writing something that sounds like a vulnerability report. The hard part is demonstrating what is actually true. That distinction is becoming more important as AI becomes more common in security workflows. AI can accelerate discovery, but validation still depends on knowledge: knowledge of systems, protocols, application behavior, identity boundaries, memory corruption, business logic, and all the implementation details that separate a plausible theory from a real exploit. The future of offensive security will not belong to people who merely produce the largest number of findings. It will belong to people and teams that can prove what matters. The Industry Is Already Seeing the Cost of Shallow AI Output The warning signs are already visible. Bug bounty programs and maintainers have been dealing with a surge of low-quality AI-generated reports, often submitted with thin evidence, templated language, and little meaningful validation. Bugcrowd publicly addressed this pattern in its policy changes around AI-generated submissions, describing a class of reports that looked polished but created unnecessary triage burden rather than a useful security signal. This is not just a bug bounty problem. It is a preview of what happens anywhere AI is used to create security findings without enough human judgment behind them. If a tool can generate a convincing write-up in seconds, organizations will receive more reports, more alerts, and more claims. Unless those claims are validated, the result is not better security. It is a larger queue. Security teams are already overloaded with scanner output, dependency alerts, cloud configuration issues, and compliance findings. Adding AI-generated speculation on top of that does not help unless the quality bar goes up at the same time. A finding should answer basic questions clearly: what happened, how it was reproduced, what the attacker controls, which boundary was crossed, and what the demonstrated impact is. Without that, the report may be interesting, but it is not ready to drive engineering action. “Looks Vulnerable” Is Not the Same as Vulnerable One of the most dangerous habits in offensive testing is confusing a suspicious pattern with a validated vulnerability. AI can make that habit worse because it is good at explaining why something might be bad. A model may see user input near a database query and describe SQL injection. It may see a URL fetch and suggest SSRF. It may see a dangerous API in a code path and describe remote code execution. Sometimes the model is pointing at a real issue. Other times, it is missing the conditions that decide whether the issue matters. A tester still has to prove reachability. Does the attacker-controlled input actually reach the dangerous operation? Is authentication required? Is authorization enforced somewhere else? Is the vulnerable feature enabled? Does the production configuration expose the code path? Does the application normalize, encode, sanitize, or reject the payload before it matters? Does the issue cross a trust boundary or merely affect an internal-only path with no practical security impact? These questions are where real offensive security begins. They are also where shallow automation often breaks down. AI can generate hypotheses quickly, but hypotheses are not findings. A good tester treats AI output as a lead to investigate, not a conclusion to forward. Why Knowledge Still Matters The best offensive security practitioners are valuable because they understand systems, not because they can run tools. Tools have always been part of the job, but tool output has never been enough. A web scanner may identify a parameter that reflects input. A static analyzer may flag a dangerous function. A fuzzer may produce a crash. A language model may describe a plausible attack path. In every case, someone still needs to understand what the signal means. That understanding is usually earned through repetition. Senior researchers spent years doing the work manually: tracing requests, reading source, reverse engineering binaries, debugging crashes, writing exploit code, breaking authentication flows, and learning how real systems fail. That process builds memory and instinct. It teaches a practitioner when a finding is probably real, when a tool is being misled, and when a small bug may become serious if chained with something else. This kind of knowledge is hard to fake. It shows up in the questions a tester asks. It shows up in the way a report is written. It shows up in whether the tester can explain the exploit path without hiding behind generic language. Most importantly, it shows up when the first attempt fails. A person who understands the system can adapt. A person who only accepts the tool’s explanation is often stuck. AI Can Make Good Testers Faster, but Can Also Make People Rusty There is a real concern among experienced practitioners that overdependence on AI can make people rusty. This is not an anti-AI argument. It is a human learning argument. When a tool answers every question instantly, it becomes tempting to stop remembering details. When it writes the first version of every script, it becomes tempting to stop practicing. When it explains every code path, payload, crash, and error message, it becomes tempting to stop building the mental model yourself. That convenience has a cost. Offensive security rewards depth, pattern recognition, and technical recall. The hardest findings often come from recognizing that a behavior in one area violates an assumption somewhere else. They come from knowing how parsers, frameworks, allocators, identity providers, and authorization systems have failed before. They come from seeing the connection between small details that do not look important in isolation. If practitioners stop exercising those muscles, they lose some of the very skill that makes them effective. The risk is not that AI makes security professionals useless. The risk is that people let AI do too much of the thinking too early, then mistake fluency for competence. Prompting is useful, but it is not a replacement for judgment. Most AI-Assisted Testing Still Uses Familiar Techniques A lot of AI security marketing can make it sound as if machine learning is discovering vulnerabilities through some entirely new kind of reasoning. Sometimes models do surface patterns a human might miss, especially across large and unfamiliar codebases. That is useful. But in many practical offensive testing workflows, the underlying techniques are still familiar: enumerate endpoints, inspect parameters, trace data flow, compare authenticated and unauthenticated behavior, generate payloads, run fuzzers, observe responses, and determine whether the application state changed in a security-relevant way. In other words, many AI-enabled systems are orchestrating known testing techniques at scale. They can plan, execute, observe, and iterate faster than a human doing everything by hand. That is a meaningful improvement, but it does not remove the need to understand the result. If the system reports an authorization flaw, someone still has to know whether the object relationship matters. If it reports a memory corruption bug, someone still has to reason about reachability, crash context, mitigations, and exploitability. If it reports an API weakness, someone still has to determine whether the observed behavior violates the application’s trust model. The most valuable use of AI is not to replace those decisions. It is to reduce the mechanical work around them so skilled testers can spend more time on analysis and validation. What Good Validation Looks Like A validated offensive finding should be specific, reproducible, and tied to impact. It should not require the reader to guess why the issue matters. The report should make the exploit path clear enough that an engineer can reproduce it and a security leader can understand the risk. That does not mean every issue needs a dramatic exploit chain or a movie-style proof-of-concept. It means the evidence should support the claim. For AI-assisted testing, teams should draw a sharp line between leads and validated findings. A lead is something worth investigating. A validated finding is something that has been tested and proven. Mixing those categories creates confusion and wastes time. A good workflow can absolutely use AI to generate leads, but the promotion from lead to finding should require evidence. Practical Validation Checklist A practical validation standard does not need to be complicated. Before a lead becomes a reported finding, the tester should be able to answer questions like these: What specific behavior was observed, and where did it occur? What attacker-controlled input, identity, or state was required? What security boundary was crossed, such as authentication, authorization, tenancy, trust, privilege, or memory safety? What exact steps reproduce the behavior in the target environment? What is the demonstrated impact, not just the theoretical worst case? What evidence shows that the issue is reachable and relevant in the deployed configuration? What would a fix need to change, and how can the team confirm that the fix works? This kind of checklist helps keep AI in the right role. It can help produce candidates, suggest test ideas, and speed up reproduction. It should not be allowed to skip the step where a human verifies the claim against reality. The Human Role Is Still Technical One of the underappreciated realities of AI security platforms is that human validation remains deeply important behind the scenes. That should not be surprising. Offensive security has always required judgment, and judgment is especially important when findings become consequential. The person reviewing the evidence has to decide whether the exploit path is realistic, whether the environment matters, whether the issue is isolated or chainable, and whether the severity claim is justified. This is not just an administrative quality-control function. It is technical work. Authorization flaws often depend on business logic and object relationships. API vulnerabilities may require understanding how roles, tenants, and resources interact. Memory corruption requires reasoning about crash state, control, mitigations, and exploit primitives. Cloud findings depend heavily on identity, trust policies, and service-specific behavior. AI can assist with all of this, but it does not remove the need for someone who knows what they are looking at. The higher the impact of a finding, the more important the human role becomes. Organizations do not want a confident guess when the result may affect engineering priorities, customer trust, compliance obligations, or executive risk decisions. They need proof. Avoiding Exaggerated Impact AI-generated reports can also overstate severity. Reflected input is not cross-site scripting until script execution is demonstrated. A URL fetch is not meaningful SSRF until the tester can show access to something the attacker should not reach. A dangerous function is not remote code execution unless reachability, control, and execution can be proven. These mistakes are not just embarrassing; they erode trust between security teams and engineering teams. It happens quite often that a finding will get a rating of CVSS 9.8, when in fact it might not even be a finding at all. Experienced researchers are careful with impact because they know it has to be earned. A bug in an admin-only feature does not carry the same risk as an unauthenticated internet-facing bug. A crash may be a denial of service, a path to code execution, or simply an unexploitable reliability issue, depending on the context. A missing check in one code path may be serious, or it may be protected by a control somewhere else. The only way to know is to validate. Good validation prevents both underreporting and overreporting. It helps testers avoid crying wolf, but it also gives them the evidence needed to make a strong case when the issue is genuinely serious. Tenable also recently brought up challenges in this space, including how there are often critical contextual combinations that are also missed. How Teams Should Use AI Without Losing Skill The right goal is not to avoid AI. The technology is too useful for that. The right goal is to use it in a way that strengthens offensive testing instead of weakening the people doing it. AI should help testers move faster, explore more hypotheses, and reduce repetitive work. It should not become a substitute for learning how systems behave. Security leaders can encourage that balance by setting expectations around evidence and training. Junior testers should still learn fundamentals before they outsource too much of the process. Senior testers should use AI as a force multiplier, not as an authority. Teams should review not only whether a finding was generated, but whether the tester can explain and reproduce it. That explanation is where real understanding becomes visible. A healthy AI-assisted offensive testing program should reward validated impact over volume. It should measure signal quality, not just finding the count. It should preserve manual practice in areas like request manipulation, code review, debugging, exploit development, threat modeling, and impact analysis. It should also use AI as a teaching tool: when the model suggests an issue, the tester should ask why, test the claim, and learn from the result. The Standard Has Not Changed: Prove It AI will continue to improve. Agents will become better at navigating applications, reading code, generating payloads, and documenting results. Some of this progress will be genuinely impressive, and security teams should take advantage of it. But offensive security cannot become a volume game where every plausible theory becomes someone else’s triage burden. The core standard of the field is still simple: prove it. Prove the bug exists. Prove the attacker can reach it. Prove the impact. Prove the business risk. Prove the fix works. AI does not lower that standard. If anything, it raises the importance of enforcing it, because convincing but unproven output is now easier to produce than ever. The best researchers and teams of the next decade will not be the ones that reject AI. They will be the ones who combine automation with technical judgment, using the machine to accelerate the work without handing it the final say. Knowing when to stop, inspect, test, and think will remain a competitive advantage. Knowledge still matters because validation still matters, and in offensive security, validation is the difference between noise and truth. I will be expanding on this topic in SEC660: Advanced Penetration Testing, Exploit Writing, and Ethical Hacking at SANS Network Security 2026. Our course update blends together manual understanding of complex topics, such as exploit writing, and instructs how to leverage AI to assist in automating specific tasks. Note: This article has been expertly written and contributed by Stephen Sims, SANS Fellow.
thehackernews.comJul 16, 2026extracted
Product showcase: Trust Chain TPRM turns vendor compliance evidence into verified assurance
Product showcase: Trust Chain TPRM turns vendor compliance evidence into verified assurance Trust Chain is an AI-native third-party risk management (TPRM) solution by Strike Graph that replaces the security questionnaire model with validated evidence of compliance. Rather than asking vendors to self-report their security posture, Trust Chain requires vendors to submit evidence, which is then evaluated using Strike Graph’s patent-pending Verify AI technology. The evaluation tests each submission against the requesting organization’s specific requirements. The result is verified assurance rather than vendor attestation, delivered in a fraction of the time and at a fraction of the cost of other TPRM tools. Trust Chain is built directly into the Strike Graph GRC platform, putting vendor risk data alongside an organization’s compliance frameworks, internal controls, and audit evidence in a single environment rather than a separate tool. Validate vendor compliance with evidence-based AI-validation Verify AI: The engine that tests evidence, not just collects it The core capability that separates Trust Chain from every other TPRM tool on the market is Verify AI, Strike Graph’s patent-pending AI validation engine for compliance evidence. When a vendor submits a compliance document, Verify AI tests the evidence against the specific requirement it was submitted to satisfy, determining whether the evidence demonstrates the control in question and surfacing gaps, discrepancies, and missing scope automatically. [Vendor view] Verify AI runs tests to validate the vendor’s attached evidence to ensure it satisfies the requirements listed by the customer’s description. A vendor submitting a penetration test that covers a narrower scope than required by the requesting company, or a policy document that addresses only a subset of the relevant controls, will have those deficiencies surfaced automatically rather than accepted as complete. Verify AI catches what manual review misses and what questionnaire tools never even attempt to verify. Flagged items route to the compliance team for human review, dramatically reducing the scope of manual work. Trust Chain reduces the time compliance teams spend on TPRM by 92%, from an industry average of more than 40 hours per vendor to approximately 3.5 hours, by handling the initial evidence testing automatically. Verify AI flags evidence that does not fully satisfy the requirements with written explanation, prompting human intervention for review. When compliance teams review flagged items, they can review the failed test reasons, leave comments, and override the results, saving their notes to the record. Leave internal comments during manual review of vendor evidence requests “Organizations have been measuring compliance claims for decades and calling it third-party risk management,” said Chris Steffen, VP of Research at Enterprise Management Associates. “What Strike Graph has built with Trust Chain is architecturally different: rather than asking vendors what their controls look like, it validates whether the evidence they submit demonstrates those controls. That’s the shift the market needs, and it’s the right direction for TPRM to move.” Continuous monitoring: Risk visibility that does not lapse between assessments Most TPRM programs assess vendors once a year and treat the completed questionnaire as evidence of ongoing compliance. Certifications lapse, audit scopes change, and security programs evolve in the months that follow, and the compliance team has no visibility into any of it until the next assessment cycle begins. Trust Chain replaces the point-in-time model with automated supply chain monitoring. Compliance teams define exactly what vendors need to prove through Trust Chain’s Evidence Request Libraries, starting from a standard set of evidence types or converted directly from an existing questionnaire. Requirements can be assigned uniformly across the vendor portfolio or tailored per vendor relationship to reflect differences in risk tier, data access, or regulatory exposure. Assign evidence from the pre-loaded Evidence Request Library across all vendors or add tailored requests based on individual vendor risk level Compliance teams also configure evidence expiration schedules for each requirement, specifying how long a document (i.e. SOC 2 report, penetration test, or policy) remains valid before a recollection is required. When evidence approaches its expiration date, Trust Chain automatically sends vendors a new submission request without any intervention from the compliance team. Risk visibility becomes continuous rather than annual. View real-time assessment status and progress by vendor for each evidence request Real-time dashboards surface which vendors are fully verified, which have pending submissions, and which have active gaps without manual tracking of renewal dates or follow-up email chains. Compliance teams can also enrich each vendor record with internal context that remains within the platform: a manual vendor score, a status designation, and notes that reflect business decisions beyond what the evidence alone shows. If Verify AI flags an item as a known and approved risk, teams can override the flag directly, keeping the audit trail intact without creating false remediation work. For items requiring vendor action, reviewers can leave specific comments tied to the submission, giving vendors direction on what to resubmit rather than routingfeedback through email. Approve and score vendors for internal team visibility with optional notes The vendor experience: Submission replaces redundant questionnaires Rather than completing custom questionnaires for every customer relationship, Trust Chain gives vendors a centralized platform to store and submit compliance evidence — from access control policies, incident response plans, and business continuity documentation, to penetration test results, audit reports, and certifications — in order to meet their customer’s specific requirements. Verify AI validates each submission and shares the results with the requesting organization rather than the underlying documents themselves, so vendors retain control over their compliance documentation unless they choose to share it directly. When a submission falls short, vendors receive the customer’s comments alongside a specific request to resubmit, giving them direction without routing the back-and-forth through email. Vendors working across multiple customer relationships can easily use Trust Chain to prove compliance without duplicating the redundant work that makes questionnaire-based TPRM so costly for vendors to participate in. The Vendor Portal shows all evidence requests and submissions with status, due dates, and requester The friction reduction for vendors is measurable. Trust Chain achieves an 84% vendor response rate compared to an industry average of roughly 67%, a direct result of replacing the questionnaire burden with a submission model that respects vendors’ time. Why questionnaires cannot meet today’s compliance obligations The case against questionnaire-based TPRM is not just operational, it is increasingly legal. Under CMMC Level 2, a named Affirming Official is personally responsible for annual compliance affirmations covering an organization’s vendor and supply chain security. The CMMC assessment methodology requires that each security control be evaluated against three criteria: correct implementation, operational effectiveness, and desired outcome. A completed vendor questionnaire satisfies none of them. A completed questionnaire captures only what a vendor chooses to say about their own controls, which is precisely what CMMC’s assessment methodology is designed to move beyond. As Justin Beals, CEO and Co-Founder of Strike Graph, writes in his article “Affirming Official’s dilemma: Why security questionnaires fail under CMMC Level 2”, an Affirming Official who relies on questionnaires to attest to vendor compliance faces potential False Claims Act exposure under deliberate ignorance or reckless disregard standards. The regulatory framework itself makes it clear that self-reported assertions are not evidence of the implementation of controls. The same principle applies beyond CMMC. Michael Rasmussen, founder of GRC 20/20 Research and widely recognized as the father of GRC, draws a sharp distinction between evidence collection and evidence assurance in his analysis of AI in GRC. A completed questionnaire does not mean the answer is accurate; a document attached to a control record does not mean the control is operating effectively; and AI that only accelerates evidence collection may simply produce more artifacts and greater false confidence. Verify AI is built to close that gap, moving from collecting evidence to validating whether it demonstrates what it claims.
helpnetsecurity.comJul 15, 2026extracted
Compromised jscrambler 8.14.0 npm Release Drops Rust Infostealer During Install
The jscrambler npm package was compromised, and simply installing its 8.14.0 release runs an infostealer on your machine. Published on July 11, 2026, the malicious version carries a preinstall hook that drops and executes a native binary, one build each for Windows, macOS, and Linux. Socket flagged the release six minutes after it was published. If you or one of your build systems pulled it in that window, the payload has already run with whatever access your install process had. None of this is in the prior release, 8.13.0. The package diff shows two new files under dist/: setup.js, a small loader, and intro.js. Despite the name, intro.js is not JavaScript but a roughly 7.8MB container packing three gzip-compressed native binaries, one each for Linux, Windows, and macOS. On install, setup.js picks the binary for the host operating system, writes it under a random name in the system temp directory, marks it executable, and launches it detached with its output hidden. The added files are in the published package, but nowhere in jscrambler's public source. StepSecurity and SafeDep both pulled and analyzed the release, and both report no matching commit, tag, or pull request for 8.14.0 in the GitHub repository. Its latest tag is still 8.13.0. The version was pushed straight to npm under a legitimate maintainer account, bypassing the project's normal release flow. That points to a compromised npm account or build pipeline. Which of the two has not been established. The payload is a Rust infostealer, built for all three platforms, that sweeps a developer machine for secrets and ships them to a drop server over TLS, according to Socket's updated analysis and a statement to The Hacker News. The target list is broad and aimed at developers: cloud credentials from AWS, Azure, and Google Cloud, including the metadata endpoints CI runners use; cryptocurrency wallets and seed phrases from MetaMask, Phantom, and Exodus; the Bitwarden password manager vault; browser-stored passwords and cookies; and Discord, Slack, Telegram, and Steam sessions. It also goes after something newer: the config files for AI coding tools, including Claude Desktop, Cursor, Windsurf, VS Code, and Zed, where API keys and Model Context Protocol server credentials tend to sit. The binaries do more than steal. On Linux, the payload links the kernel's BPF library and can load an eBPF program straight into the kernel from memory. That is a foothold in the kernel, not the userspace file access that the rest of the stealer relies on. StepSecurity and SafeDep both flagged the capability, though what the eBPF does is still being pulled apart. The Windows and macOS builds add anti-debugging checks, and the stealer wires in persistence to survive a reboot: a hidden Windows scheduled task set to relaunch every minute, and a macOS LaunchAgent that reloads on login. Its command-and-control details stay encrypted in the binary and never surfaced in static analysis. StepSecurity's runtime monitoring caught the dropped binary reaching out to two hard-coded IP addresses and to Tor infrastructure, the first network indicators published for the campaign. jscrambler is a build-time tool, installed as a development dependency or run from CI. Those environments hold what the stealer collects: cloud keys, deploy tokens, and source code that a build or CI process can reach. The package sees about 15,800 downloads a week, and how many pulled the compromised version is not yet known. That is a far smaller footprint than the packages hit in the big npm compromises of the past year, which pull billions of downloads a week between them. For a stealer aimed at build machines, though, reach was never the point. The access is. The Shai-Hulud worm ran from an install hook to steal tokens and spread through hundreds of packages that September. The widely used chalk and debug packages were taken over through a phished maintainer account and used to reroute crypto payments. In March, a hijacked account pushed a cross-platform trojan into Axios, an HTTP library with more than 83 million weekly downloads. What makes the timing here sharp is that npm had just moved against this exact route: npm 12 shipped on July 8, three days before this release, with dependency install scripts off by default. On npm 12, a preinstall hook like this one does not run unless someone approves it. Older clients still run them automatically. Version 8.15.0 has since replaced it at the top of npm's version list, published from the same maintainer account and showing none of the malware alerts 8.14.0 tripped: no install script, no bundled binary. But 8.14.0 was not pulled. It is still on npm, so any lockfile or command pinned to it keeps installing the stealer. Only the main CLI package was hit; the jscrambler plugins for webpack, gulp, Metro, and grunt stayed on their clean June releases, with no install hooks. What to do now Get off 8.14.0. Move to 8.15.0, or pin to 8.13.0 for a release from before the incident, and clear [email protected] from lockfiles and caches. Work out whether you installed 8.14.0. Check lockfiles and package-manager logs for [email protected], and CI records for any run of dist/setup.js, from July 11 on. The loader drops its payload under a random name in the temp directory, so there is no fixed binary name to grep for; line up install timestamps against Node child processes and temp-directory execution instead. On Windows, check Task Scheduler for hidden tasks; on macOS, inspect ~/Library/LaunchAgents for unfamiliar plists. If 8.14.0 ran on a machine, treat every secret it could reach as stolen, not just exposed. Rotate cloud keys, npm and GitHub tokens, and AI-tool and MCP API keys; revoke Discord, Slack, browser, and Bitwarden sessions; and move any crypto out of wallets on that host. Block the two command-and-control IPs listed below. The cleanup was fast, but a stealer does its work in the seconds after install. A build pinned to 8.14.0, on an older client that runs install scripts, still runs the payload. And on any machine that already ran it, the secrets were gone before 8.15.0 ever reached the top of the list. Indicators of compromise Malicious package: [email protected]. SHA-256 hashes for the added files and their decompressed payloads: dist/setup.js: a742de963f14a92d24ebcbc7b44ac867e23a20d31d1b0094a13a4f83287f4e60 dist/intro.js: a41a523ef9517aab37ed6eea0ec881821bdcb7aefcb5c5f603adc7907f868c86 Linux payload: fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd Windows payload: b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903 macOS payload: c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd Network endpoints StepSecurity observed at runtime. The two IPs are the direct attacker endpoints; the binary also reaches Tor infrastructure, likely for connectivity or routing: C2 IP: 37.27.122[.]124 C2 IP: 57.128.246[.]79 Tor infrastructure: check.torproject[.]org, archive.torproject[.]org On-host artifacts: a randomly named hidden file in the system temp directory, of the form .{random} or .{random}.exe on Windows, plus a hidden Windows scheduled task or a macOS LaunchAgent for persistence. Update: More Malicious Releases, and Jscrambler Confirms a Compromised npm Credential Jscrambler has confirmed the cause: the attacker published the packages using a compromised npm publishing credential. Socket now ties five malicious jscrambler versions to the same actor, pushed over about three hours, and all carrying the same cross-platform infostealer described above. They are 8.14.0, 8.16.0, 8.17.0, 8.18.0, and 8.20.0. Jscrambler's advisory lists four of them and does not mention 8.18.0, so treat all five as suspect until the two accounts agree. Version 8.15.0, published between the first two, is on neither list and appears clean. The delivery method changed partway through. Socket reports that 8.14.0, 8.16.0, and 8.17.0 run the malware from a preinstall hook, the same route as the first release. In 8.18.0 and 8.20.0, the dropper was moved into the package's main code and CLI, so it fires when the package is imported or run, and npm install --ignore-scripts does not stop it. Jscrambler's advisory describes only the preinstall vector. Jscrambler says the intrusion was limited to the jscrambler package for its Code Integrity product and did not reach its other products. It revoked and rotated its publishing credentials and secrets, hardened its publishing pipeline, and deprecated the malicious releases, though deprecation still leaves them installable by exact version. Its forensic investigation is ongoing. Both Jscrambler and Socket point to 8.22.0 as the clean release to move to. If you installed any affected version, upgrade to 8.22.0 and audit the workstation or CI runner that pulled it, rotating the credentials listed in the steps above. Jscrambler says npm currently reports zero downloads of the malicious versions but cautions that the count lags by hours and is still being verified, so it is not yet proof that nothing ran. Update: JFrog Ties the Payload to IronWorm and Finds a Self-Propagation Routine The malware does not just steal. It is built to spread itself. JFrog, which analyzed the same five releases, identifies the payload as IronWorm, a Rust infostealer it documented a month earlier and ties to the Shai-Hulud lineage. JFrog says the payload hunts for npm tokens in environment variables and files such as .npmrc, checks them against the registry, picks packages with high download counts, and injects a malicious setup.mjs preinstall script into their tarballs, and publishes the infected versions straight to registry.npmjs.org through a raw HTTP PUT, without ever calling the npm client. It confirmed the routine in the code. It does not say the worm managed to publish anything through a stolen token. Where the analyses overlap, they agree. JFrog lists the same five versions, 8.14.0, 8.16.0, 8.17.0, 8.18.0, and 8.20.0, including the 8.18.0 that Jscrambler's advisory left out, and its payload hashes and the two command-and-control IPs match the indicators already published. The target list is wider than the first reports showed. Alongside cloud keys and wallets, JFrog says the stealer reaches for VPN configuration files, the 1Password and Bitwarden vaults, Tor hidden-service keys, and, pointedly, the install folders of red-team frameworks such as Metasploit, Sliver, and Havoc. That last target points at security researchers and penetration testers. The malware runs its own Tor client to carry its command channel, which accounts for the Tor addresses in the earlier indicators. For bulk theft, though, JFrog says it uploads stolen data straight to temp.sh, a public file host, over a direct connection that leaks the victim's real IP. Add temp.sh and the propagation script setup.mjs to the indicators worth watching. If you ran an affected version, the npm token rotation in the steps above also removes the credential this worm needs to spread.
thehackernews.comJul 11, 2026extracted
The open source library holding up your stack might have one maintainer
The open source library holding up your stack might have one maintainer Every serious software product runs on code that someone else wrote and released for free. A web service leans on a cryptography library, a data pipeline pulls in a parser, and a mobile app ships a handful of small utilities that one person maintains in spare time. All of it carries the same label. A new paper argues that the single label hides differences large enough to change how each piece behaves once it lands in production. Researchers sorted open source software into fourteen sub-genres, each defined by who starts and sustains a project and to what end. Their review screened close to four thousand unique papers drawn from two scholarly indexes. The result is a typology, along with an argument that the kind of project a study samples sets how far its conclusions travel. One label covers many kinds of project A community Linux distribution, a single-vendor database, a university research library, a humanitarian health-records system, and a one-person utility differ in why they exist, who decides their direction, and how the work gets paid for. The authors give the differences names. Community-driven projects such as Debian and Arch Linux run on volunteers and merit-based authority. Company-backed projects such as Elastic, MongoDB, and GitLab sit under one firm that earns revenue from the software and controls its roadmap. Foundation-governed projects such as Apache HTTP, Kubernetes, and Eclipse live under a vendor-neutral nonprofit that holds the trademark and keeps competing firms on even terms. Other categories sit further from the usual picture. Multi-company co-opetition covers rivals who build shared infrastructure together, as firms do around OpenStack and the Linux kernel. Research and scientific software gets written inside labs by domain scientists working to grant cycles and academic careers. Protestware covers packages a maintainer alters or sabotages to send a political or economic message, with node-ipc and colors.js as examples. Why the category predicts behavior The practical point lands on funding and governance, since those two things predict how a project holds up once many people rely on it. Critical digital infrastructure is the sharp case. Components such as OpenSSL, curl, and log4j sit underneath much of the software ecosystem, and a few volunteers often keep them running. Nadia Eghbal described this sustainability problem in a Ford Foundation report, and later research formalized it as underproduction, a state where the labor a component receives falls short of how widely it is relied upon. Studies of the npm ecosystem show a related risk, where a small number of maintainer accounts reach much of the network. Hobbyist and solo projects carry the same fragility. Researchers call this a low truck factor, which is a way of asking how many people would have to walk away before the whole thing grinds to a halt. For a one-person project, the answer is one. When that maintainer gets busy, burns out, or moves on, the code stops moving with them. A project backed by a foundation with member dues and paid staff has more people to lean on when the same thing happens. The community itself differs too The differences run deeper than money. Take open source for social good, or OSS4SG, the projects built to help people rather than turn a profit, things like the health-records system OpenMRS or the crisis-mapping tool Ushahidi. People who show up to these projects tend to stay. The authors call them “sticky.” Conventional projects are “magnetic,” pulling in a crowd where plenty pass through and move on. The road from first-time contributor to trusted core member looks different too, and in OSS4SG people reach that core faster and by more than one path. So a playbook for keeping contributors around, built on one kind of project, can fall flat on another. Where the category leaves off For anyone who works in IT, this lands close to home. The typology is still a work in progress, a light review the authors treat as a starting hypothesis, so the categories will shift as more research comes in. The practical read holds up anyway. Before your org commits to an open-source tool or pulls in a new dependency, the category tells you something a star count never will. An open-core product from a single vendor comes with relicensing risk tied to that vendor’s business plans. A solo package comes with bus-factor risk, the odds that one person walking away breaks it. A foundation-backed project comes with the governance that lets competitors share it in the first place. Knowing what kind of project you are dealing with puts the risk in plain sight before the code ever ships. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
helpnetsecurity.comJul 10, 2026extracted
_HELP_ME_ESCAPE_FROM_BELARUS_PLEASE_ [Guest Diary], (Tue, Jul 7th)
by Jason Callahan, SANS.edu BACS Student (Version: 1) [This is a Guest Diary by Jason Callahan, an ISC intern as part of the SANS.edu BACS program] Every so often a honeypot hit comes along that is less about the exploit and more about the intent behind it. While reviewing DShield logs I ran into a scanning bot that caught my eye: a URI string that appeared to be a plea for help. On 2026-06-06 my DShield honeypot logged back-to-back HTTP requests from the same source IP hitting two different ports with both carrying an identical, oddly formatted request path: The request path itself /?_HELP_ME_ESCAPE_FROM_BELARUS_PLEASE_ is not a known exploit path, it appeared to be a plain-text message in the URL. Searching my logs for that particular string returned around a dozen similar HTTP requests over a 2 months period. These came from various IPs from around the globe with no discernible pattern which pointed to a self-propagating bot rather than a single attacker. Further research showed that this bot was first reported to ISC in May 2026. The number of reports peaked shortly after the first report before a sharp drop and has remained steady since. [1] I was unable to locate much more information about this bot other than a reddit thread on r/selfhosted describing the same requests hitting a Traefik reverse proxy. According to that thread, the user emailed the address embedded in the User-Agent and received a reply pointing to a page on a free web-hosting service. The page is a static HTML document with no scripts and it lays out what the bot is & why it exists. The author, who identifies himself only as “Alex,” claims to be based in Belarus and writes that the bot is intentionally limited: no exploits, no command-and-control, no persistence. In his words, paraphrased and summarized from the page: • The bot scans random IP addresses for open HTTP ports (80, 8000, 8080) and SSH ports (22, 2222). • If it finds an open HTTP port it sends a single request (GET, CONNECT, or HEAD) • If it finds an open SSH port it attempts a brute force with a small, fixed list of default credential pairs (admin:admin, root:root, etc.) • It runs fully autonomously with no C2 channel; discovered IP/credential pairs are reported back to a loader only. • It does not establish persistence, typically running from /tmp, and it is designed to self-terminate roughly six months after release. • The stated purpose is to draw attention to conditions in Belarus. They describe it as a “performance piece,” saying they are not seeking funding and only asking for non-financial help leaving the country (job leads, advice, connections). Disregarding the origin and supposed intent of the bot, this is a straightforward scan-and-brute-force bot and it should be treated like any other hitting a honeypot. The HTTP request is reconnaissance/fingerprinting that tells the operator a host is alive and reachable on that port. The risk is on the SSH side: any host reachable on TCP 22/2222 that still uses a default or weak credential pair is exposed, regardless of the creator’s stated intentions. I want to give some healthy skepticism here rather than take the linked page at face value. I have no way to verify the age, location, or motive claimed on that page, whether the page itself is the full extent of the bot's behavior, or whether the “self-terminate after six months” and “no persistence” claims hold up under closer reverse engineering. Sob stories and appeals to sympathy are also a known social-engineering lever, and a URI designed to make analysts pause and read a web page rather than immediately blocklist an IP is an effective way to buy a scanner some goodwill. None of that changes the defensive posture: treat it as an untrusted, credential-guessing scanner. [1] https://isc.sans.edu/weblogs/urlhistory.html?url=Lz9fSEVMUF9NRV9FU0NBUEVfRlJPTV9CRUxBUlVTX1BMRUFTRV8= [2] https://isc.sans.edu/honeypot.html [3] https://www.sans.edu/cyber-security-programs/bachelors-degree/ Disclosure: Claude was used for grammar and polish checks. No further use of generative A.I. was used in the creation of this post. ----------- Guy Bruneau IPSS Inc. My GitHub Page Twitter: GuyBruneau gbruneau at isc dot sans dot edu
isc.sans.eduJul 9, 2026extracted
Qilin Dominates Ransomware Market Amid Growing Cybercrime Consolidation
The ransomware ecosystem is moving from fragmentation back to consolidation, with Qilin emerging as the dominant ransomware-as-a-service (RaaS) operation after the disruption of major groups including LockBit and RansomHub. Yet despite Qilin's strong position, the rapid emergence of other groups, such as The Gentlemen, demonstrates how quickly the cybercrime landscape continues to evolve. Lotem Finkelstein, VP research at Check Point, highlighted that based on the cybersecurity firm’s research in their 2026 Cyber Security Report, Qilin now holds around 16% of the cybercriminal market share. Qilin has been active since at least October 2022 and today operates a technically mature infrastructure. Speaking to Infosecurity Finkelstein said, "Over the last few months, what we have observed is that they are consolidating again and becoming major ransomware groups." Recent data from Sophos X-Ops Counter Threat Unit (CTU) seen by Infosecurity showed that over the last 12 months, from July 2026, Qilin has listed 1496 victims on its data leak site. Meanwhile, Akira stands at 1205 and The Gentlemen at 763. Aiden Sinnott, principal threat researcher, Sophos X-Ops CTU, concurred with Finkelstein’s assessment, "Qilin has become dominant largely because it was the main beneficiary of ransomware market consolidation following major law enforcement activity.” The attraction for affiliates to join the Qilin operation comes because it offered high affiliate payouts, mature infrastructure, continuous technical innovation and expanded extortion services. This came at exactly the time that competing RaaS programs such as LockBit, ALPHV and RansomHub were collapsing. “The result was a rapid influx of experienced affiliates and a sharp increase in victim volume," Sinnott said. Finkelstein added that affiliates are now empowered with AI tools to conduct their campaigns, meaning the barrier to entry is lower and less technical knowhow is needed for aspiring cybercriminals. The Gentlemen Rises However, according to Comparitech data there is another group that looks to be vying for market domination. The cybersecurity reviews platform found that in June 2026 The Gentlemen knocked Qilin off the top spot for the first time in many months, becoming the month's most prolific ransomware strain with 115 victims, compared to Qilin's 78. Rebecca Moody, head of data research at Comparitech, noted that over half of Qilin’s targets tended to be US-based, however less than one in five of the Gentlemen’s June victims were from the US. Research published by Check Point in April found that The Gentlemen was gaining traction among affiliates and is increasingly targeting enterprise environments using a mix of modular tooling and cross-platform payloads. A leak of an internal database used by the group in May showed operational information about their infrastructure, affiliates and victims. This leak included screenshots from ransom negotiations, showing a successful case where the group received $190,000, after starting with an initial demand (anchor) of $250,000. Qilin's Growth Could Bring Challenges Whether Qilin will retain the top-spot as the year progresses is yet to be seen. But Finkelstein highlighted that with notoriety comes unwanted attention from international authorities. He said expects law enforcement will undoubtedly look to act against Qilin in the future, as they did with LockBit. “When [ransomware operators] were so fragmented, law enforcement wasn’t able to focus on a specific one of them, and now, when they have a group like Qilin growing so fast, we should expect [law enforcement action]." Finkelstein noted that the group has become very creative regarding its tactics, using phishing campaigns as well as vulnerability exploitation. On June 9, Check Point disclosed that a vulnerability in its own Remote Access VPN and Mobile Access solution was targeted by Qilin. Luckily, Finkelstein said, this only affected one customer. “It was only a single case but it was one too many,” he said. Check Point is using its Frontier AI Models Readiness Program to detect vulnerabilities in its own product portfolio. As part of this program, the company has conducted large-scale AI-driven code scanning across our products, performed extensive security reviews, hardened components where needed, refined our time-to-patch procedures, and accelerated our protection development processes to meet the pace of emerging AI-driven threats.
infosecurity-magazine.comJul 3, 2026extracted
ToddyCat: your hidden email assistant. Part 2
Introduction We continue to share details on the malicious techniques and toolsets used by the ToddyCat APT group. In the first part of this report, we examined the group’s attacks aimed at stealing data from browsers, as well as from local and cloud email services. The methods used in that campaign indicated that ToddyCat was attempting to access corporate correspondence while evading monitoring tools. However, all of the group’s methods we described previously are effectively detected by EPP and EDR solutions. The attackers continued their search for ways to bypass security solutions and developed a new tool to gain access to a victim’s cloud account via the Google API. Armed with this tool, the group automated all stages of the attack and managed to remain undetected by monitoring systems. In this part of the report, we break down the mechanics of this new attack and analyze the tool that was used to automate it. We’ll also discuss how to detect and defend against this threat. Umbrij In this campaign, the attackers focused their attention on corporate email communications hosted on Gmail, targeting access compromise via APIs. Because the Google API relies on the OAuth 2.0 protocol for authorization, applications can use an OAuth token to access requested email resources. To acquire this token, the threat actors developed a tool called Umbrij and used it to connect to the browser’s management console in headless mode via a remote debugging port. Through a series of requests, they obtained an OAuth authorization code, which they subsequently exchanged for an access token to reach the target resources via the API. We have dubbed this technique Shadow Token via Remote Debug (STRD). This attack is viable on Chromium-based browsers. If the user has not logged out of their Gmail account, the browser maintains an active session. The attackers exploit this: they launch the browser, connect via the remote debugging port to take control, and send a request to the Gmail service to grant access to the Google account resources within the context of the user’s saved session. During our investigation of this attack, we discovered several versions of the Umbrij tool. These versions included a variety of helper functions designed for debugging, as well as for searching and selecting user accounts within the browser, among other tasks. Kaspersky solutions detect this tool with the following verdicts: HEUR:Trojan-PSW.MSIL.Umbrij.gen, HEUR:Trojan.MSIL.Agent.gen, HEUR:Trojan-PSW.MSIL.Agent.gen. Execution The Umbrij tool was discovered during a proactive threat hunting operation: a scheduled task, KasperskyEndpointSecurityEDRAvp, was running on a user host, launching a digitally signed file. Kaspersky solutions do not create scheduled tasks with that name; the attackers were attempting to masquerade their malicious activity as a legitimate process. The signed file then used the DLL sideloading technique to load the malicious tool. Throughout our observation period, we identified the following legitimate files vulnerable to the DLL sideloading technique that were used to launch Umbrij: BDSubWiz.exe: a component of the Submission Wizard in Bitdefender ConnectAgent, which is used to support connection features and interaction with other Bitdefender services or agents. This file insecurely loads a file named log.dll. VSTestVideoRecorder.exe: a component of the video-recording tool used for testing with Visual Studio (VS Test). This executable insecurely loads a file named Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll. GoogleDesktop.exe: the discontinued Google Desktop Search application for indexing files and performing quick searches on a local Windows computer. This executable insecurely loads a file named GoogleServices.dll. These files were used to load different versions of Umbrij; the same legitimate file could be leveraged to launch more than one variant. In total, we discovered three versions of Umbrij, which we refer to as a, b, and c for convenience. The tool itself is a DLL written in .NET and obfuscated with ConfuserEx, an open-source obfuscator for .NET applications. Umbrij is managed with the help of parameters passed through a command line at startup, although it is occasionally executed without any parameters. Below are examples of the command lines observed in attacks against users: However, these are not the only parameters the tool can accept and process. During the analysis of its executable code, we discovered additional parameters that vary depending on the version of Umbrij. See the table below for the parameters and their descriptions. Environment preparation At startup, the tool evaluates several prerequisites required to carry out the attack and performs preparatory actions to subsequently compromise the Gmail account. First, Umbrij verifies the availability of the port that will be designated for browser debugging. To accomplish this, the tool utilizes a function named ChekPortAvailable() (original spelling retained), which accepts the target port number as a parameter. It then retrieves information about active connections on the host using the .NET GetActiveTcpConnections() function from the System.Net.NetworkInformation namespace. The tool iterates through each connection in a loop, comparing the port number to the one it is checking. After this, the tool retrieves the user context. It searches the system for the explorer.exe process and duplicates its token, retaining all of its privileges (T1134.003 Access Token Manipulation: Make and Impersonate Token). This is the exact same mechanism used by another tool in the group’s arsenal, TomBerBil, which we covered previously. By default, Umbrij duplicates the token of the first explorer.exe process it encounters. If multiple users are logged in to the system, the -user switch can be used to specify the name of the target user whose token to duplicate. If the -runas-currentuser switch is specified, the tool will execute within the context of the current user without duplicating any tokens. Next, Umbrij constructs the path to the browser application folder within the user’s local application data repository. To do this, it uses the Environment.SpecialFolder.LocalApplicationData command to retrieve the repository directory from the environment variable and appends the directory of the target browser. The tool then searches for the Local State file in the following folders: %LOCALAPPDATA%\Google\Chrome\User Data\Local State %LOCALAPPDATA%\Microsoft\Edge\User Data\Local State See below for an example of the Local State file structure. Within this file, the tool searches for the info_cache array, which stores information about browser user profiles. Umbrij enumerates all user profiles and looks for those containing a user_name field that includes an email address. The presence of an email address indicates that the user is authenticated to a Google service. While the tool can interact with every profile it finds, if the -regex parameter is passed through a command line, it searches for the specified substring within the email addresses being enumerated and proceeds exclusively with those matches. Next, Umbrij creates the following directories for Google Chrome and Microsoft Edge, respectively: %LOCALAPPDATA%\Google\Chrome\BackupFiles\ %LOCALAPPDATA%\Microsoft\Edge\BackupFiles\ The tool copies the following user files and folders of each target user profile into these directories: IndexedDB: a folder containing a relational database used for client-side storage of structured data Local Storage: a component of the browser’s web storage that provides a key-value mechanism for storing data on the client side Network: a folder where the browser stores files related to network requests and caching, such as the network cache and session files Login Data: a file that stores saved passwords for various websites and applications Login Data For Account: a file that stores credentials associated with a Google account or other synchronized accounts within the browser Preferences: a file containing profile-level browser settings Secure Preferences: a file that stores protected configurations, such as security and synchronization data Web Data: a file that stores auto-fill data If these files are locked by other processes, the tool includes a dedicated function to force-copy them. As the next step, the tool searches the “Program Files” and “Program Files (x86)” directories for the browser installation folder. Once it locates the executable file and successfully copies all required files, it is ready to proceed with acquiring the authorization code. Acquiring the authorization code In the next phase of execution, Umbrij launches Google Chrome, Microsoft Edge, or both browsers sequentially, depending on the parameters passed in the command line. It then passes arguments to the browser based on the following template: It populates the template with the following values: {0}: the path to \BackupFiles\, where the user profile files were copied {1}: the path to the browser executable file {2}: the remote debugging port number The table below describes the parameters used in this browser launch template: The browser process runs in headless mode while utilizing the copied user profile. Consequently, all active user cookies are applied, which means sites with saved credentials will skip authentication prompts. Furthermore, the browser will log history to a new folder, keeping it completely hidden from the user’s primary account view. Through this method, the threat actors gain access to the user’s authenticated sessions — specifically their Google account — along with the ability to erase any trace of their activity within the browser. Next, the tool uses the Puppeteer Sharp library, a .NET version of Puppeteer, to connect to the remote debugging port. Puppeteer provides a high-level API to control Chrome or Chromium browsers over the DevTools protocol. Its primary use is for automated testing. If the connection to the remote debugging port is successful, Umbrij sends a GET request to direct the browser to the following URL: The value specified in the client_id field belongs to Google Workspace Migration for Microsoft Outlook (GWMMO). This is Google’s official tool for importing email, calendar events, and contacts from Microsoft Exchange accounts or local PST files into a Google Workspace account. Umbrij also includes the ability to switch the client_id value from 279448736670 to 1095133494869 by using the -sync parameter. This second identifier belongs to another application: Google Workspace Sync for Microsoft Outlook (GWSMO), which allows users to sync email, calendars, and other data from the cloud account directly into Microsoft Outlook. The remaining parameters used in the request differ from those typically utilized by the legitimate applications. See the table below for a comparison of these parameters: As seen from the list above, Umbrij omits several parameters characteristic of the legitimate applications. For instance, Umbrij drops the code_challenge parameter, normally used for data protection when retrieving an authorization code. Additionally, the tool modifies the redirection address: while the legitimate application specifies a dedicated port and a callback path, the tool simply points to localhost. The authorization code request specifies the set of permissions for Google services required by the application. This list also differs significantly between requests issued by the legitimate application and those generated by Umbrij. The table below details the variations in the requested scopes: After the browser navigates to the URL provided by Umbrij, the Google account selection page opens. Because the attackers copied the victim’s profile folder and are operating within their specific environment, the account selection options will include the currently signed-in user’s authenticated session. Umbrij identifies the corresponding element within the page’s HTML source code. The tool uses JavaScript to emulate a mouse click on the elements, allowing it to proceed to the next step. The subsequent step opens a page displaying the list of requested permissions. As shown in the screenshot, Umbrij requests full access to email, cloud storage, and contacts. Just like in the previous step, it uses JavaScript to click the “Allow” button, which completes the authentication process. The browser is then redirected to the local address that was specified in the redirect_uri parameter of the initial request. The tool intentionally omits a port and a path to a specific page in the redirect_uri because the true objective of this action is simply to capture the code parameter from the context of the GET request. This parameter contains the OAuth authorization code. To retrieve it, Umbrij extracts the substring located between the code= and &scope parameters. Results Umbrij, like most other tools in ToddyCat’s arsenal, logs its actions in detail and saves them to a file. It also saves the retrieved authorization code to this log file, which the operator subsequently exfiltrates from the compromised host. Below is an example of a log file generated by version a of the tool. The log indicates that the sync mode is selected (meaning the Google Workspace Sync for Microsoft Outlook application is used) and the debugging port is set to 11111. After locating the user profile and copying its folder, Umbrij launches Google Chrome. After this, the tool emulates clicks on the appropriate buttons to confirm permissions, ultimately outputting the final result of the operation: the stolen OAuth authorization code. Since all requests occur within a background browser instance, the tool includes a feature to generate a PDF snapshot of the web page where the permission confirmation process halted in the event of an error. Additionally, the tool can create a PDF file for the user profile in Google Chrome and Microsoft Edge by navigating to the following internal addresses: edge://profile-internals chrome://profile-internals Example contents of a generated PDF file The acquired authorization code is then exchanged for an OAuth access token. The threat actors use that token to connect to the Gmail account through the API, thus compromising corporate email communications. The diagram below illustrates the complete attack workflow. Detection DLL sideloading First and foremost, defenders should monitor library loading events (DLL loads) associated with the known applications vulnerable to DLL sideloading that are exploited by this tool: Bitdefender ConnectAgent, Visual Studio, and Google Desktop Search. Browser launch Launching a browser with a remote debugging port specified is a highly unusual event on standard user hosts that are not running web application development or automated testing workflows. Consequently, monitoring for these specific command-line arguments can serve as a reliable indicator of this attack. Revoking third-party access To review the authorization codes granted to applications, navigate to the Google Account settings under the Third-party apps & services section, or access the following URL directly: This page displays a comprehensive list of applications and services that currently have permission to access the account. If the Google Workspace Migration for Microsoft Outlook or Google Workspace Sync for Microsoft Outlook applications appear in this list but are not actually used within your organization, revoke their access immediately. This will invalidate all potentially compromised OAuth tokens associated with them. Risk mitigation Launching a browser with a remote debugging port enabled is inherently suspicious for users who do not engage in web development. For these employees, you can completely disable Chromium-based browser developer tools. This can be achieved by configuring the DeveloperToolsAvailability policy. To enforce this, set the registry value to 0x00000002 for the following Windows Registry key and restart the browser: To verify that the policy has been successfully applied, navigate to the browser’s internal policies page at chrome://policy: Note that while disabling developer tools can successfully disrupt the automated retrieval of the OAuth authorization code, it will not help, however, if the adversary decides to leverage the browser’s graphical user interface (GUI) — though this manual approach is significantly less likely due to the friction it introduces for the attackers. Therefore, as a risk mitigation measure, users should be instructed to explicitly log out of their Google accounts as soon as their sessions are complete. Takeaways The ToddyCat APT group continues to search for ways of compromising corporate email communications. We have been tracking the group for a long time and we have observed continuous updates to its arsenal in an attempt to bypass security defenses, even as their core techniques remain consistent. For instance, the group has long relied on DLL sideloading to stealthily drop malicious utilities and scheduled tasks. However, their new tool, Umbrij, automates the attackers’ attempts to gain access to organizational email accounts. This automation not only helps increase the scale and frequency of their attacks but also demonstrates ToddyCat’s strong motivation and advanced technical skills. To defend against these threats, corporate security teams must monitor for suspicious library loading events initiated by legitimate files, watch for instances of browsers launching in developer mode, and conduct regular audits of third-party applications and services with access permissions to Google accounts. Furthermore, deploying a robust, comprehensive security solution — such as Kaspersky Next — is critical to detect this type of malicious host-based activity in a timely manner. Indicators of compromise Additional information about this threat is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: [email protected]. Malicious files 1AB58838E5790EFB22F2D35AB98C0B7D Umbrij ver. a A7D7D6C4C3F227F7117261C63B9E23A9 Umbrij ver. a 3D3A621F852C42D97FD7260681E42508 Umbrij ver. a 3432DD9AC0DF80EF86EB80BD080F839B Umbrij ver. a 22AAEB4946BA6D2F2E27FEB7DBB295DE Umbrij ver. b F61FBFB7AA1CD5DC8F70B055B51563E2 Umbrij ver. b F169D6D172DFB775895A5E2B1540C854 Umbrij ver. c Legitimate files leveraged for DLL sideloading Paths to DLL sideloading files
securelist.comJun 30, 2026extracted
Most teams accept higher risk for faster AI database work
Most teams accept higher risk for faster AI database work Database professionals are using AI for everyday work like writing queries, building schemas, and reviewing code, and a growing share rely on autonomous tools that act on the database itself. The use of AI in database management has almost tripled in a year, climbing from 15% to 44% of organizations, according to Redgate’s 2026 State of the Database Landscape report. That puts AI inside the systems holding an organization’s most sensitive data, often with permission to change that data directly. The security problem here is one the people running these systems already see coming. Data security ranks as their top worry about AI, named by close to two-thirds of respondents and by even more of those whose organizations have yet to adopt it. The same group is going ahead anyway. A majority accept higher data security risk in exchange for the speed AI gives them, a choice many made before the controls were in place to support it. Autonomous tools with standing access Most of the attention on AI in this space goes to generative tools that draft code and queries. The sharper issue is the next category. A majority of organizations use autonomous AI and agents, software that can operate on database systems with limited human review of each action. These tools handle data quality work, schema design, and automation, and almost every organization reports getting something useful out of them. “AI can be the good and the bad here. It can analyze threats and find issues automatically, so it can strengthen my own system’s security. The concern is mainly how people deal with it (like uploading confidential information to ChatGPT), or when you give it too much power. Granting AI the permissions to automatically fix everything means it can potentially also cause huge damage,” said Ben Weissman, CEO, Solisyon. Weak controls underneath fast change The foundations that would contain that risk are thin. Most organizations still depend on manual steps to test and deploy database changes, few use formal data governance frameworks, and metadata management remains rare. Monitoring is spread across a mix of vendor products, scripts, and home-grown solutions. AI speeds up how fast database code and schemas change, and faster change makes mistakes easier to introduce and harder to catch before they hit production. Data quality compounds the problem. A large share of respondents report quality issues surfacing when data moves between systems, the exact conditions where automated changes do the most harm. Gartner has tied many AI failures to unready data and predicts that most projects lacking AI-ready data will be abandoned by the end of 2026. Shadow AI in the data layer Much of this AI use sits outside any defined workflow. Individuals pick their own tools to move faster, and those habits stay informal and ungoverned. The pattern looks like earlier waves of shadow IT, now operating against the data store. Weissman pointed to the everyday version of it: people pasting confidential information into tools like ChatGPT. A minority of respondents remain uneasy about feeding company data into AI at all, and a small share of organizations have banned it outright. Many more limit use to an approved list, and that approved-only group is growing. Some organizations are adding structure. Most now provide formal guidance on AI use, a sharp rise from a year earlier. The technology is changing teams too. Around half of respondents say their actual work has drifted from their job description, and a similar share of organizations are hiring fewer junior staff because of AI. Exposure set to grow The number of AI tools in use will keep climbing. More than eight in ten respondents expect to bring on additional AI tools in their roles over the next one to two years, with growth concentrated in large, cloud-based environments that hold the most data. Spending backs that up, with heavy investment from large enterprises in particular. The questions security practitioners need to ask are old ones about identity, least privilege, auditability, and rollback, now pointed at a new actor with elevated rights over sensitive data. “AI is accelerating at a pace the world has never seen, but it’s only as powerful as the data that feeds it and databases are the crown jewels of the intelligence space. The data professionals who guard and govern these data ecosystems will determine whether AI becomes humanity’s greatest innovation or its most consequential mistake,” said Kellyn Gorman, Multi-platform and AI Advocate at Redgate Software.
helpnetsecurity.comJun 29, 2026extracted
Chinese Framework Powers 200,000 Scam Sites
More than 200,000 websites are using investment scam templates built with the Chinese open source framework Uni-App, Infoblox reports. A cross-platform development toolkit, Uni-App allows developers to create Vue.js codebases that can be deployed as mobile and desktop applications, or as mobile-optimized websites simultaneously. Widely used in China and supported by a developer ecosystem, the framework powers thousands of legitimate products, and its maker DCloud does not appear to be involved in its fraudulent use. However, Infoblox discovered that threat actors are selling investment scam templates, and that numerous scam websites using such templates appear linked to the same cluster of activity. “Beyond the technical connections, we also uncovered patterns in the growth of the DCloud investment sites, along with coordinated dips in new domain registrations seen across scam websites on diverse hosts, an indication of a centralized owner facing disruption or making coordinated changes across all their DCloud investment scam sites,” the cybersecurity firm notes. Infoblox identified over 236,000 second-level domains powering the scam infrastructure, ranging from fake crypto exchanges to fake gambling, brand impersonation, WhatsApp phishing, and multi-language pig-butchering websites. Among them is the infamous RainbowEx platform, a fake cryptocurrency platform that made international headlines after thousands of residents of a small Argentine town were duped into pouring money into it. Hosted across numerous providers, the scam second-level domains have been launched since mid-2022, with an increase observed since late 2024, after the RainbowEx scandal. “After October 2024, that figure jumped to roughly 15,000 newly observed sites per month at peak. The framework appears to have become a known platform within the scam-operator ecosystem due to the coverage it received by major news outlets,” Infoblox notes. The largest portion of DCloud-fingerprinted sites consists of investment scam domains, run by multiple unrelated operators, “possibly dozens, even hundreds,” the cybersecurity firm says. In addition to fake cryptocurrency exchanges and ‘deposit-and-trade’ platforms, they also include crypto wallet drainers, prediction-market and gambling impersonators, messaging platform phishing, and other phishing and credential-harvesting sites. Lightning Shared Scooter Co. (LSSC), an operation that likely caused millions of dollars in losses in the US, was also using Uni-App. It promised investors sharp increases in passive revenue through funding a high-tech scooter-sharing company, and increased its sense of legitimacy through physical storefronts. A similar scooter-investment operation, Yuechi Sharing Technology Ltd. (YST), currently active in Australia, New Zealand, and the United States, also has a frontend built using the Uni-App framework. YST, Infoblox says, has legitimate registration paperwork but is connected to a network of other investment-scam websites. “For the last two years, there’s been a dramatic scaling up of scam websites using the DCloud framework, and operators of these sites continue to launch complex real-world schemes to trick victims. It’s overdue to holistically track threat actors operating in this ecosystem and attempt to identify commonalities that indicate shared ownership of the sites,” Infoblox notes. Related: Google, Meta, Microsoft Among Signatories of Pact to Combat Scams Related: Meta Launches New Protection Tools as It Helps Disrupt Scam Centers
securityweek.comJun 27, 2026extracted
Professional Athletes and Wearables
Professional Athletes and Wearables I haven’t thought about the privacy issues surrounding professional athletes and wearables. Wearables present serious privacy issues for “Average Joe” consumers, who are entrusting tech companies to safely store and protect their biometric data. Imagine the stakes for a professional athlete, whose entire livelihood could be affected by a single biometric data point. To give one of many realistic hypotheticals: a basketball player has a terrible game, and the coach wonders if they showed up to the gym hungover. The coach has access to the player’s wearable data, and checks to see when they went to sleep, as well as what their heart rate looked like during the night. Should the player have been out partying before a game? No. Should the coach be able to surveil them? Definitely not. It will not surprise you to learn that there’s an emergent gambling angle here: sports leagues would love to commercialize players’ biometric data, and sharp bettors would love access to data about, say, a hungover player. “We’re going to get to a spot where people are betting not just on the velocity of the puck that was shot by a player in the NHL playoffs, but on what the heart rate of a certain player is going to be running down the field,” said Helen “Nellie” Drew, the director of the University of Buffalo’s Center for the Advancement of Sport, and a professor of practice in sports law. There are other practical considerations, too. What if wearable data reveals that a player isn’t as speedy as they were before, and a team uses that data against the player during contract negotiations? What if a wearable reveals a player is favoring their leg, or is at greater risk of injury? This information is potentially beneficial to a training staff and an athlete, so long as it’s disclosed and used in a responsible manner—a critical, mostly unresolved caveat. “Aging and injured players are the most at-risk” of wearable data being used against them, said Michael LeRoy, who researches sports labor laws and AI, and is a professor at the University of Illinois’s School of Labor and Employment Relations. The bit about gamblers is particularly scary. I have often said that surveillance tech is generally deployed first against people with diminished rights: children, prisoners, military personnel, the mentally impaired. This is another early use case with different dynamics. The surveilled are wealthy and powerful, and—in many cases—unionized.
schneier.comJun 22, 2026extracted
What happens to oversight when AI agents write a lab’s own code
What happens to oversight when AI agents write a lab’s own code Inside the labs building frontier AI, a growing share of the coding gets done by the AI itself. These agents write, edit, and run software with light human oversight between steps, and they reach into production infrastructure, research pipelines, and potentially the systems that train and evaluate future models. A new analysis from researchers at the University of Oxford and SaferAI digs into the security risks that live in everything around those agents: the people reviewing their code, the pipelines watching them, and the policies that set the rules, along with the models themselves. To get there, the team borrowed three safety methods that aviation, nuclear power, and chemical plants have leaned on for decades, and pointed them at a generic frontier developer pieced together from public disclosures by Anthropic, OpenAI, and Google DeepMind. The methods are built to catch trouble that comes from parts interacting, including the case where every single part is doing its job correctly. Responsibilities without named owners Several control actions show up in published safety frameworks with no named person or team attached to them in the public record. Among them: the power to pause, restrict, or reroute a model, the job of keeping access policy current, and assessing catastrophic risk and filing its quarterly reports. Someone inside a given company may own these jobs quietly. Two of them, the catastrophic-risk assessment and the quarterly summaries, are spelled out in California’s SB 53, which requires frontier developers to assess and report catastrophic risk from internal model use. A legal duty with no owner anyone outside can point to is exactly the sort of gap the analysis wants disclosed. There is a matching gap in who controls deployment. One named role can sign off on putting a model into temporary use before an audit wraps up. The role that would pull that deployment back is missing from the public record. The two belong together, and only the one that opens the door has a name on it. When the monitor lags the model At Anthropic and OpenAI, the monitoring of internal coding agents happens offline, so the review lands after a session is over. OpenAI says it covers almost all of its internal coding traffic, around 99.9 percent, using a frontier reasoning model as the watcher, with review arriving about 30 minutes later. Anthropic runs a layered pipeline where humans get through roughly thirty summaries a week. Since the risk score can show up after a pull request has already been reviewed or merged, it often works as a heads-up after the fact. Swapping in a new model stretches that gap wider. The new model behaves differently the moment it goes live, and the monitor keeps grading it against the old one until someone updates the rules. The same thing happens when a model reaches the internal team ahead of complete pre-deployment testing, or before anyone has built monitors suited to it. Review anchored to the agent’s explanation When an agent hands off its code for human review, it sends along its own write-up of what it did and why. The reviewer reads that explanation and tends to nod along with the agent’s stated intent, which chips away at how independent the review is. This holds even for a sharp reviewer, because the agent’s self-grade comes stapled to the work being graded. A slower problem builds over months. Agent-written code, tests, and docs pile up in the codebase, and that codebase becomes both the reference the agent reads for its next task and the yardstick reviewers use to tell normal from abnormal. If the agent has consistent blind spots, those blind spots quietly settle into the very tests meant to catch them. Drift and what auditors could track Many of these conditions creep in through everyday calls that each seem sensible. Permission exceptions pile up. Monitoring rules that never flagged anything real get trimmed. Review requirements stay put as the volume of pull requests climbs. The system prompt sits untouched after a model upgrade. Every one answers the same pressures, productivity, alert fatigue, and trust, and they all lean the same way, toward a thinner safety margin. The authors are upfront about the limits. The work rests on public descriptions of how things are supposed to run, and the FRAM method assumes the wobble in a system comes from people doing their best under pressure, an assumption that falls apart if an agent is actively gaming its own controls. Their fix is a two-tier setup: aggregated or redacted indicators in public safety reports, and the complete operational data handed to a designated auditor such as a national AI safety institute. Download: Secure Foundations for AI Workloads on AWS
helpnetsecurity.comJun 18, 2026extracted
India's Telegram ban hit the UAE too. Here's how to get around it
India has banned Telegram until June 22 after the platform was used to sell access to leaked exam materials. Telegram CEO Pavel Durov accuses Indian telecom Reliance of using BGP hijacking to enforce the block, disrupting access for users as far away as the UAE. Digital rights group, the Internet Freedom Foundation (IFF) calls the ban a disproportionate, "constitutionally incompatible" response to exam fraud. The ban, and the BGP routing fallout On June 16, India's Ministry of Electronics and Information Technology invoked Section 69A of the IT Act to restrict access to Telegram nationwide until June 22, acting on a recommendation from the National Testing Agency (NTA). A separate order requires Telegram to disable its message-editing feature in India until June 30. Telegram has since moved the Delhi High Court to challenge the ban, and the court agreed to hear the matter urgently today, but adjourned it for a June 18 hearing: Delhi High Court issued notice on Telegram’s plea challenging the Centre’s temporary blocking order and granted the respondents time to file their reply along with supporting documents. The matter will now be heard at 2:30 PM tomorrow. Telegram sought interim protection against… The disruption did not stay inside India's borders. In an X post, Durov alleged that Indian telecom Reliance was "sabotaging" Telegram access for users outside India, including in the UAE, through BGP hijacking. He said the disruption looked deliberate because the reports had been ignored, framed it as possible competitive interference given Reliance's ties to Meta, and advised network operators to reject unauthorised BGP announcements from AS18101. Border Gateway Protocol (BGP) is the routing system that tells networks how to reach each other across the internet. A BGP hijack happens when a network announces ownership of IP address ranges it does not control, which can redirect, drop or disrupt traffic for the real owner. Public routing data cited by network observers shows AS18101 began announcing Telegram prefixes around the time the domestic block went live, which would explain why users outside India lost access. The routing disruption itself is not in question. Doug Madory, Director of Internet Analysis at Kentik, confirmed AS18101 hijacked Telegram's routes, though he noted RPKI route-origin validation and filtering limited how far the bad route propagated. Network researcher Anurag Bhatia independently verified it against public routing data. Technology policy researcher Pranesh Prakash traced the mechanics in a thread: the route leaked to the global internet via FLAG Telecom (AS15412), a former RCom-owned transit provider that failed to drop the RPKI-invalid announcement, which is how users in the UAE and elsewhere lost access. Wow. Reliance Communications has engaged in BGP hijacking of Telegram's IP prefixes and is leaking it globally via FLAG Telecom (AS15412) and affecting traffic far beyond India. (Is this an accident?) It is still live: cc: @anurag_bhatia @Squeal @kingslyj @AroonDeep @Aditi_muses pic.twitter.com/gVf9ddmMFC What these analysts dispute is Durov's claim that the hijack was deliberate. Prakash said plainly that he disagreed with Durov, that intentional sabotage was highly unlikely, and that he had seen zero evidence for it, reading the incident instead as a domestic block misconfigured into a global leak. Madory and Bhatia reached similar conclusions, comparing it to Iraq's 2023 block, where an attempt to cut Telegram domestically leaked the routes outward. The corporate-rivalry angle is unresolved, contrary to what Durov suggested. Following the publication of this piece, Reliance Jio also issued a statement on X: Recent posts on X have led to speculation regarding Reliance Jio Infocomm Limited (AS55836) and a BGP route misconfiguration. We categorically clarify that Jio has not been involved in any such incident. Jio continues to operate its network in accordance with global Internet… — Reliance Jio (@reliancejio) June 17, 2026 AS18101 is registered to Reliance Communications, the insolvent Anil Ambani-era operator, not Reliance Jio, the Mukesh Ambani carrier in which Meta holds a roughly 10 percent stake. But Prakash noted Jio has absorbed some of RCom's spectrum and fibre assets, and stopped short of identifying who actually originated the hijack, calling it a question reporters would need to dig into. The routing anomaly is documented. The intent, and the identity of whoever triggered it, are not established. Why India did it The trigger is the National Eligibility-cum-Entrance Test (NEET), India's largest medical entrance exam, taken by millions of students. Question papers were allegedly leaked before the May 3 exam through a paid WhatsApp group and coaching-centre networks in Rajasthan, with reports of a pre-circulated guess paper overlapping heavily with the real test. The exam was cancelled on May 12 and a re-test scheduled for June 21. India's federal investigating agency, the Central Bureau of Investigation (CBI) took over the probe and has made multiple arrests, including NTA-appointed subject experts and coaching figures. The NTA says cheating networks used Telegram channels, groups and bots to sell access to exam material and spread misinformation, and that channel administrators abused the edit feature to backdate posts and pass off altered timestamps as proof of a prior leak. That is the stated reason for the editing restriction running to June 30. The agency described the ban as a "last resort" after channel-by-channel takedowns failed to stop the fraud. Durov's counterargument is that the ban punishes the wrong people. He says Telegram removed hundreds of channels sharing leaked material and scams in India in recent weeks, and that banning the app does nothing about the insiders responsible. The ban also drew sharp political reaction. Karti P. Chidambaram, Congress MP for Sivaganga, asked on X whether blocking Telegram was really the master stroke that would stop exam paper leaks, tagging the NTA. Telegram replied to him in kind, suggesting the government should also shut every shopping mall in case one had a shoplifter, and close the roads because someone might be speeding. The problem with blocking platforms The IFF's objection is procedural as much as practical. It argues the directions exceed what Section 69A and the blocking rules actually permit, and described the move as a band-aid that fails the proportionality test: a nationwide block on a service used by more than 150 million people to address fraud committed by a handful. The deeper issue is opacity. Section 69A blocking orders in India are routinely issued without public reasons, and the list of blocked sites is not disclosed. The UK's Daily Mail, for example, has been quietly inaccessible across Indian ISPs since 2022, returning DNS resolution errors, with no stated reason and no named ministry behind the decision. It joined thousands of other sites blocked under the same provision with no public explanation. Telegram is unusual only in its scale and the fact that someone with 150 million users is shouting about it. The collateral The people hit hardest are the students the ban was meant to protect. NEET aspirants built their preparation around Telegram: free study material, paid coaching groups, lecture videos and notes that do not exist anywhere else as conveniently or as cheaply. my brother’s NEET PG notes, videos and paid study groups were all on telegram telegram got banned. so now he’s stuck messaging pirated-content scammers just to access what he already paid for to stop one leaked NEET UG paper, you broke access for thousands of honest aspirants… https://t.co/vfj00h3z81 pic.twitter.com/LkQGPcLRWS That captures the asymmetry the IFF is pointing at. The leak source walks free, the platform gets blocked, and the students who paid for legitimate access are the ones locked out. How to get around the ban Telegram has built-in support for exactly this scenario. The app ships with a proxy feature, MTProto (also called MTProxy), designed to route traffic around network-level censorship. It works by obfuscating Telegram traffic and forwarding it through an intermediary node before it reaches Telegram's servers, so an ISP blocking known Telegram IP ranges no longer sees a direct connection. The traffic stays end-to-end encrypted throughout, and the proxy operator cannot read messages or identify the account, though they can see the connecting IP address. Anyone affected by the India or UAE disruption can point their app at a working MTProto proxy and restore access without a full VPN. There are public proxy lists maintained for this purpose. StormyCloud runs a free MTProto proxy. There's also the SoliSpirit project on GitHub publishing a list of verified proxies refreshed automatically every 12 hours. Either gives you working server, port and secret values to plug in. As always, only use proxies from a source you trust: a malicious operator can log your IP and the times you connect, even if it cannot see your chats. Layering a trusted VPN on top closes that gap. How to set up a Telegram MTProto proxy (desktop) 1. In the menu, open Settings, and select Advanced. 2. Under Data and storage, click Connection type at the top of the panel. 3. In Proxy settings, select Use custom proxy, then click Add proxy. 4. Enter the MTProto server, port and secret from your chosen proxy source. Once saved, the proxy shows as online and Telegram routes through it: On mobile: the path is Settings > Data and Storage > Proxy (iOS) or Settings > Data and Storage > Proxy Settings (Android), then Add Proxy > MTProto and enter the same server, port and secret. For now, the restriction is set to lift on June 22, the day after the re-examination, with the editing-feature block running to June 30. Telegram's court challenge could shorten that, and the routing spillover into the UAE may resolve on its own as the India-side block is unwound. Until then, affected users who rely on the platform have a working route back in through an MTProto proxy. As mentioned, the proxy you choose is only as trustworthy as its operator. Updates: June 17, 11:36 AM ET: Added ANI's X post about court hearing update. June 18, 02:50 AM ET: Added Reliance Jio's statement released after publication. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comJun 17, 2026extracted
Malwarebytes earns AV-TEST Top Product award, aces other third-party tests
Our job is to protect people from online threats, and independent testing is one of the best ways to measure how well we’re doing. Malwarebytes nabbed AV-TEST’s Top Product award after scoring 17.5 points out of a possible 18 in the research organization’s most recent Windows security test. The award is the latest in a string of endorsements from third-party testers whose ongoing evaluations help keep us sharp. Here’s a closer look at the results. AV-TEST Windows Consumer Security Product Test AV-TEST’s Windows Consumer Security Product Test, which took place in March and April, assessed 14 security applications across three categories: how well they protected Windows PCs from malware, how much they slowed down a device, and how often they raised false alarms. AV-TEST noted in its synopsis: “We focused on realistic test scenarios and challenged the products against real-world threats. Products had to demonstrate their capabilities using all components and protection layers.” To receive the Top Product award, companies had to score 17.5 points or higher out of a total of 18, earning a maximum of six points in each category. Malwarebytes has received a Top Product endorsement from AV-TEST more than a dozen times since it first began taking the test in 2018. MRG Effitas Consumer Assessment Certification Malwarebytes once again came out on top in the MRG Effitas Consumer Assessment Certification, which tested eight security products to measure their ability to block malware, protect against phishing, and avoid false positives. Malwarebytes was the only company to achieve Level 1 Certification, meaning we succeeded in stopping all 300 in-the-wild infections without causing damage to the device or its data, generated zero false positives, and blocked at least 79% of phishing attempts. Our phishing detection rate was 100%. This certification is particularly impressive because the test used newly discovered malware samples, meaning most security products had not encountered them before. AVLab Cybersecurity Foundation Advanced In-the-Wild Malware Test Continuing our winning streak, Malwarebytes received a perfect score (421/421) in AVLab Cybersecurity Foundation’s Advanced In-The-Wild Malware Test, earning an “Excellent” certificate. The test applied existing threats currently circulating online, delivered the way a real user would come across them. To receive the “Excellent” certification, a security product had to stop at least 99.6% of malware threats, either before they could run or during an attack. We detected and blocked every single real-world threat in an average of 0.508 seconds—a full 3 seconds faster than the industry average. These types of independent assessments are important. They keep us on top of our game, which in turn keeps our customers safe.
malwarebytes.comJun 17, 2026extracted
In Other News: Anthropic Maps AI Threats, Unpatched Comodo Flaw, Palantir Chief Eyed for CISA
SecurityWeek’s weekly cybersecurity news roundup offers a concise overview of important developments that may not receive full standalone coverage but remain relevant to the broader threat landscape. This curated summary highlights key stories across vulnerability disclosures, emerging attack methods, policy updates, industry reports, and other noteworthy events to help readers maintain a well-rounded awareness of the evolving cybersecurity environment. Here are this week’s highlights: Threat actors poison AI chatbot queries to harvest computing power Microsoft reported that threat actors are exploiting both SEO and AI chatbot recommendations to trick users into downloading fake utilities that impersonate legitimate tools like CrystalDiskInfo and PDFgear. Once an endpoint is compromised, the attackers abuse ConnectWise ScreenConnect to secure persistent remote access and deploy a specialized binary that hollows out trusted Microsoft .NET processes. The hijacked processing power is ultimately used to run cryptocurrency miners specifically engineered to target high-performance GPUs. Grandoreiro banking trojan attacks WatchGuard researchers observed a new Grandoreiro malware campaign targeting financial institutions across Portugal and Latin America using DLL side-loading techniques that abuse four legitimate software applications. The malware has been around for a decade and it continues to be active despite law enforcement action. Self-propagating Go encryptor automates full network compromise Microsoft Threat Intelligence is tracking Storm-2697, a financially motivated group operating ‘The Gentlemen’ ransomware-as-a-service, which features an aggressive Go-based encryptor obfuscated with Garble. The malware uses password-protected command-line arguments to establish its encryption speed and automatically self-propagates across targeted networks by creating scheduled tasks with SYSTEM privileges. The Gentlemen ransomware was recently also dissected by Halcyon and Huntress. Let’s Encrypt adopts Merkle trees for post-quantum future To mitigate the massive bandwidth bloat caused by post-quantum cryptographic algorithms, Let’s Encrypt is adopting Merkle Tree Certificates to secure future web authentication infrastructure. By batching certificates under a single signature rather than authenticating them individually, this new approach significantly shrinks TLS handshake sizes while inherently baking in certificate transparency. The certificate authority plans to launch a staging environment for these optimized post-quantum certificates in late 2026, followed by a full production rollout in 2027. Federal agencies sound alarm on exposed tank gauge systems CISA, the FBI, the NSA, and other US agencies are warning critical infrastructure operators about threat actors actively exploiting internet-exposed Automatic Tank Gauge (ATG) systems used for remote liquid and fuel monitoring. Attackers are bypassing authentication and leveraging OS command execution to modify configurations, prompting the government to urge facilities to immediately disconnect ATGs from the public internet. Attacks on ATGs at US gas stations were recently linked by officials to Iran. Palantir technology chief eyed for CISA director role The Trump administration is reportedly considering Palantir Technologies Chief Technology Officer Shyam Sankar to serve as the next director of CISA. If nominated, the longtime Palantir executive would step into the vacant leadership position as CISA faces significant budget cuts. Tom Parker, a security services lead at IBM, was recently also positioned as a frontrunner for the role. Malware infection triggers leak of Ultrahuman data Indian health technology vendor Ultrahuman disclosed a data breach exposing user contact details, transaction history, and wellness metrics for a fraction of its customer base. The threat actor gained unauthorized, read-only access to an internal analytics system by leveraging credentials stolen from a malware-infected employee laptop, though the company confirmed no passwords or payment details were compromised. Crypto-miner hitches a ride on Hola Browser Sophos discovered an XMRig crypto-miner binary quietly bundled within a certified version of the Hola Browser installer for Windows. Hola attributed the anomaly to a localized supply chain compromise affecting a small segment of its distribution pipeline, which allowed the unauthorized payload to evade detection. AI attack mapping exposes rapid rise in autonomous agentic scaffolding A year-long Anthropic analysis mapping AI-enabled cyber operations against the MITRE ATT&CK framework reveals a sharp increase in threat actors leveraging LLMs for high-risk activities like lateral movement and credential dumping. The AI giant concluded that an attacker’s threat level will soon be dictated by the external agentic scaffolding they build to orchestrate autonomous attack chains. Malformed IPv6 packet triggers unpatched Comodo firewall crashes Security researcher Marcus Hutchins released details and a PoC exploit for ComoDoS, a critical vulnerability residing in Comodo Internet Security. The unpatched flaw enables remote attackers to crash targeted Windows endpoints by sending a single malformed TCP/IP packet, effectively bypassing all configured firewall rules. Hutchins said he attempted to responsibly disclose the flaw, but received no response from the vendor. SecurityWeek was unable to contact Comodo for comment.
securityweek.comJun 5, 2026extracted
Zero trust physical security needs trust decisions at the edge
Zero trust physical security needs trust decisions at the edge In this interview with Help Net Security, Chuck Davis, VP, Global Information Security at Hikvision, explains how zero trust applies to physical security systems like cameras and door controllers. He breaks down how to make trust decisions at the edge without recreating old perimeter assumptions, why these devices should be treated as IT assets, and what the Mirai botnet taught the industry. Davis also covers posture assessment for devices that cannot run standard agents, and how to manage device identity and revoke trust across tens of thousands of endpoints during a live incident. Zero trust orthodoxy says “never trust, always verify,” but a physical security system has a brutal constraint: a 200-millisecond door unlock decision cannot wait for a cloud-based policy engine experiencing latency. How do you architect trust decisions at the edge without quietly reintroducing the perimeter assumptions you are trying to eliminate? One of the biggest misconceptions about zero trust is the assumption that every authorization decision must travel to a centralized policy engine in real time. I hear this used regularly as a reason to carve out physical security systems from zero trust architecture entirely, as if the 200-millisecond constraint on a door controller is somehow an exemption from sound security principles. It is a design constraint, and there is a well-established architecture for meeting it without abandoning the core zero trust principle that nothing should be trusted just because of where it sits on the network. Zero trust does not require centralized decision execution. It requires centralized trust governance. Those are different things, and keeping them straight is what makes edge enforcement work. The model I prefer in this situation, is distributed trust with centralized policy. Policy creation, identity governance, and authorization logic stay centralized. Enforcement happens locally at the edge, where latency and operational continuity actually matter. The architecture that enables this separates the Policy Decision Point (PDP) from the Policy Enforcement Point (PEP). The PDP determines whether access should be granted based on identity, context, policy, and risk signals. The PEP, which lives on the edge controller or access device, executes that decision locally. The door opens in well under 200 milliseconds. The policy governing that decision was authored, validated, and pushed from a centralized system. The critical detail is that local enforcement does not mean local trust. Edge devices should operate against cryptographically signed policies with short-lived credentials and well-defined access boundaries. Policies are distributed and cached locally, but remain governed centrally, refresh on a defined cadence, and are subject to revalidation. A controller should never be trusted simply because it sits inside a particular VLAN or building network. That is the old perimeter security model in disguise, and it has a way of quietly creeping back into zero trust architectures if you are not deliberate about keeping it out. This is where organizations get into trouble operationally. You start with a well-designed architecture and a 90-second policy cache lifetime. Then a network hiccup causes a door to fail to unlock and someone submits a facilities ticket. Rather than fixing the underlying network reliability issue, the security team extends the cache lifetime to avoid receiving another complaint. Ninety seconds becomes 30 minutes, becomes four hours, becomes a 12-hour offline grace period. At that point you no longer have zero trust at the edge. You have a slowly drifting perimeter, and nobody documented it as a security decision because it happened one exception at a time. The architecture also requires a deliberate answer to the fail-safe versus fail-secure question, and the answer is not the same for every door. Emergency egress systems are often designed to prioritize availability and life safety, so they should default open under degraded network conditions. Highly restricted environments may require the opposite. Those outcomes need to be explicit architectural decisions, not accidental side effects of a dropped network connection. Ultimately, zero trust is not about routing every decision through the cloud. It is about ensuring that wherever decisions are made, they are identity-aware, constrained, continuously validated, and revocable. The 200-millisecond door controller is not an exception to that principle. It is just a particularly clear illustration of why the architecture has to be designed for the environment it operates in. A Hikvision device sits at a fascinating intersection: it is simultaneously an IoT endpoint, a data processor, and a physical actuator. When you are conducting a threat model for a customer’s environment, which of those three identities generates the most dangerous blind spots, and can you walk us through a real scenario where that blind spot was exploited? The framing of your question assumes organizations are actively managing all three of those identities and just getting one wrong. The more common challenge across the industry is that the foundational shift has not fully taken hold yet: physical security devices are still not universally treated as the IT assets they are. There is a tendency to think of physical security equipment only in terms of its physical purpose. A camera is a camera. A badge reader is a badge reader. An NVR is a recording appliance. That framing shapes everything downstream: how the devices are inventoried, how they are maintained, and how cyber risk for those systems gets assigned across the organization. The moment a physical security device connects to a network, it becomes something else entirely. It becomes an embedded compute platform running an operating system, authentication services, APIs, a web interface, a database, encryption functions, and remote management capabilities. When physical security and IT operate in separate silos, that risk often falls into the gap between them. That gap is where the blind spots live. The scenario that brought this into sharp focus for the broader security industry was the Mirai botnet in 2016. Mirai’s operators scanned the internet for IoT devices, including large numbers of IP-connected security cameras and DVRs, and compromised them at scale by logging in with factory credentials that had never been changed. No zero-day exploits. No sophisticated tradecraft. Those compromised cameras were recruited into a botnet used to launch some of the largest distributed denial-of-service attacks ever recorded, including the October 2016 attack against Dyn that took down Twitter, Reddit, Netflix, and large portions of internet infrastructure for hours. What made Mirai so damaging was not the sophistication of the attack. It was that the industry had not yet established consistent standards for how these devices should be deployed and secured. Devices were internet-exposed without firewall protection. Security hardening guidance was inconsistent or absent. Network monitoring on physical security segments was rare. Mirai exposed the gap between how these devices were being deployed and how they needed to be managed as networked IT assets. That is the blind spot. Not a sophisticated attack against a complex threat model. Internet-exposed cameras, running factory defaults, with likely nobody watching the traffic they were generating. Most of these controls are not novel. The challenge is operational discipline. Isolate physical security devices on their own network segment. Place them behind a firewall with no direct inbound access from the internet. Keep firmware current. Follow manufacturer hardening guidance. If remote access is required, use a VPN or zero trust network access solution. If an attacker cannot reach your security camera, they cannot attack it. Physical security infrastructure is enterprise IT infrastructure. The most important architectural shift is recognizing it as such and managing it accordingly. Firmware is the soft underbelly of physical security devices. What does a zero trust posture assessment look like for a camera or access reader that cannot run an EDR agent, cannot be patched during business hours, and may have a seven-year depreciation cycle baked into a facilities budget? A mature zero trust assessment for these environments starts by accepting an uncomfortable reality: many physical security devices will never achieve the same security telemetry or control depth as enterprise laptops and servers. Trying to force traditional IT security assumptions onto them leads to frustration and poor risk decisions. The goal is not perfect visibility. The goal is risk reduction through compensating controls. The concept I find most useful here is what I call the trust envelope. Rather than trying to instrument the device directly, you define and enforce a boundary of acceptable behavior around it. What should this device communicate with? Which protocols? How often? At what volume? That profile, captured through network telemetry from adjacent infrastructure, becomes your posture proxy. A camera that should only communicate with a local video management server should not be initiating outbound connections to unfamiliar infrastructure. Anything outside the envelope is worth investigating. On the device side, the assessment should focus on what you can actually validate. Secure boot and signed firmware verification provide stronger assurance that the device is running what it is supposed to be running. A software bill of materials (SBOM) gives you the component-level inventory you need to know when a vulnerability in a third-party library inside that firmware actually affects you. I would take that a step further and argue that a network bill of materials (NetBOM), a structured inventory of what devices exist, their expected communication patterns, and their approved network dependencies, is equally important. Without that foundation, you are making security assertions against an unknown baseline. Surrounding the device, least-privilege networking does the heavy lifting when endpoint controls are unavailable. Segmentation, deny-by-default firewall rules, and tightly scoped management access through dedicated out-of-band networks collectively limit what an attacker can do even if a device is fully compromised. You may not be able to see inside the box, but you can control what the box can reach and who can reach it. Lifecycle governance is where many organizations fall short. Facilities budgets assume seven to ten years of operational use. Security expectations move considerably faster. That gap widens quietly until a device that still functions perfectly well is running firmware nobody is updating anymore. At that point it stops being a technical problem and becomes a business risk decision. Replacement thresholds, vulnerability disclosure monitoring, and procurement standards tied to vendor support commitments all need to be part of the assessment framework from the start. The real maturity test is whether the organization can detect a compromise quickly, isolate the affected device cleanly, and keep it from becoming something larger. Identity for human users is hard enough. For physical security devices, you are dealing with device identity at scale, sometimes tens of thousands of endpoints in a single campus deployment. What does credential compromise look like when the “user” is a PTZ camera, and how do you revoke trust from a device that is bolted to a ceiling in a restricted zone during a live incident? Identity for human users is hard enough. Device identity at scale is a different problem entirely, and the physical security environment makes it harder in ways that do not get enough attention. A campus deployment managed with shared credentials or static API keys is not a device identity program. It is an asset list with false confidence attached to it. Shared credentials do not compromise the way a human account does. There is no failed login from an unusual location, no suspicious authentication time, no behavioral anomaly a security team can correlate against a user profile. Few environments have written detection rules for a PTZ camera behaving like an authenticated user account. What credential compromise looks like for a physical security device is more subtle. Configuration changes initiated from unexpected management sources. Outbound connections to destinations outside the device’s established communication baseline. Firmware version mismatches against what the asset inventory says should be running. Authentication attempts to the management plane from IP addresses that are not the designated controller. None of those are exotic indicators. They are just indicators that most physical security environments are not actively watching for. The scale problem compounds everything. When thousands of devices share a credential pool, a single compromise does not affect one device. It potentially affects all of them, and you may have no clean way to determine which ones were accessed or what was done. The architecture that makes this manageable is individual device certificates issued from an enterprise PKI with automated enrollment and renewal. One certificate per device. Defined lifetime. Automated renewal. A device that fails to renew, or whose certificate is explicitly revoked, loses authenticated access. Certificate support varies significantly across manufacturers, ranging from basic certificate import through a web interface all the way to full automated lifecycle management with SCEP enrollment, OCSP revocation, and API-driven certificate rotation. Those are not the same thing, and procurement teams should ask specifically which capabilities a device supports before assuming enterprise PKI integration is possible. Identity without automated rotation eventually becomes credential management debt. Certificate lifecycle automation may become an increasingly important differentiator in physical security procurement. The groundwork for revocation has to be laid before an incident, not during one. The authorization to execute isolation actions needs to be pre-granted. The network hooks need to be pre-configured. The mapping from every device to its switch port, VLAN, and management controller needs to exist in the asset inventory before something goes wrong. When that preparation is in place, quarantining a compromised device becomes a VLAN reassignment or an ACL update from the network access control platform, executed remotely in under a minute without dispatching anyone to the physical location. Where certificate-based identity is deployed, revocation can close authenticated sessions quickly, though the speed depends on whether the environment uses real-time OCSP checking or CRL-based revocation. Device identity at scale requires deliberate architecture, tested processes, and clear ownership. The time to build that foundation is before an incident makes it urgent.
helpnetsecurity.comJun 2, 2026extracted
Infosecurity Europe: AI SOCs Will Still Need SOC Analysts, Security Vendors Say
Offerings of fully autonomous security operations centers (SOCs) are flourishing on the cybersecurity market and trigger anxiety about a future with empty desks. In reality, however, top security vendors exhibiting at Infosecurity Europe 2026 actually agree on one thing: AI won't replace the SOC. It will replace the mind-numbing copy-pasting and routine ticket-taking. Speaking to Infosecurity, Brett Candon, VP of International at Dropzone AI, said AI is shifting the traditional multi-tiered SOC model into a leaner, smarter operation powered by accelerated ‘tier-1.5’ analysts and strategic engineers. AI SOC: A Glass Box, Not a Black Box Automation has promised to fix the SOC for over fifteen years, but vendors argue that true autonomy requires absolute transparency. Candon emphasized that AI must be treated as a supportive "glass box" rather than a mysterious black box. The goal, he noted, is to replace heavy manual investigation work while logging every procedural step so human analysts can easily audit the machine's rationale. Patricia Titus, Field CISO at Abnormal AI, agreed that human-in-the-loop validation remains a non-negotiable safety net. Organizations still need sharp minds to verify that the machine is performing accurately. "You actually need someone who understands that to be able to go back and analyze the data periodically to make sure the tool, the AI tool, is actually catching what you want it to catch,” she said. Furthermore, an AI is only as good as the security data infrastructure supporting it. Yonni Shelmerdine, chief product officer at Vega Security, pointed out that AI cannot bypass fundamental data architecture gaps. If critical security logs are frozen or filtered out due to high cloud storage costs, human engineering is required to fix the underlying pipeline. Shelmerdine warned that if the data is gone, "no super-duper AI bot will be able to help." Intern Tier-1 and Professional Tier-1.5 SOC Analysts Rather than eliminating entry-level professionals, this technological shift is entirely redefining their daily responsibilities, the three vendors told Infosecurity. Instead of losing hours to repetitive data gathering, junior defenders are stepping straight into the role of what Candon called “tier-1.5 analysts,” acting as supervisors and auditors of AI-driven investigations from day one. According to Candon, when AI handles tedious initial triage at machine speed, the human impact changes drastically. He noted that job satisfaction has increased and employees feel like they are doing more useful tasks within the SOC, allowing organizations to promote junior staff into specialized roles much faster than traditional timelines allowed. Titus echoed this sentiment, noting that while tier-1 is traditionally where green SOC analysts "cut their teeth" on foundational security concepts, AI radically accelerates this onboarding period. Analysts can learn the basics significantly faster by reviewing and dissecting the automated workflows generated by an AI companion. To operationalize this shift, Titus shared a practical blueprint from her own security team's experience. After deploying Abnormal AI's behavioral models, her team realized they no longer needed to hire five permanent, full-time “tier-1 ticket takers,” as she put it. Instead, existing full-time staff were instantly elevated to handle high-risk, "truly tier-3 level investigations,” she explained. Titus then transformed the remaining tier-1 responsibilities into a university intern program, bringing in college students to learn the grassroots basics of email security and behavioral analytics alongside the AI. Titus strongly advocated against completely erasing entry-level roles, stating: "I think we would be foolish to eliminate tier-1 SOC analysts, largely because what happens if something happens and AI stops working, you need people to be able to go back to the grassroots and handle that tier-1." She explained that, by the time these interns graduate, they intimately understand how to audit AI systems and manage security posture, creating a direct pipeline of highly skilled full-time hires. Emergence of A “Cyber Defense Engineer” Role in AI SOCs As analysts climb the value chain, Vega’s Shelmerdine anticipates the rise of an entirely new industry archetype: the cyber defense engineer. Advanced defenders are increasingly shedding the passive analyst title to think of themselves as active system builders. "AI isn't going to replace the SOC, it's a cyber defense engineer who will," Shelmerdine said. He described these modern professionals as engineers who control their SecOps platforms using advanced management protocols and natural language, effectively "vibe coding their queries, their hunts, their dashboards, their reports, [and] their triage." Rather than reacting defensively to an infinite queue of alerts, their daily focus shifts toward proactively engineering better detection postures and tuning AI tools. Ultimately, the consensus across security vendors is clear: the autonomous SOC is not an empty room, but a significantly smarter one. By stripping away the manual triage work that has plagued security operations for more than a decade, AI is acting less like a human replacement and more like a talent rescue mission, transforming burned-out ticket takers into strategic cyber engineers. However, against a stark backdrop of sweeping corporate layoffs currently hitting the broader tech and cybersecurity sectors, it remains to be seen whether this idealistic vendor optimism will hold true or if economic pressures will ultimately tempt enterprises to sacrifice human expertise for pure automation. You will be able to find Abnormal AI, Dropzone AI and Vega Security at Infosecurity Europe at Booths #D145, #E40 and #F160, respectively. Register for Infosecurity Europe here.
infosecurity-magazine.comJun 1, 2026extracted
UK Cyberspying Chief Calls AI ‘an Unstoppable Force’ and Warns About Russia
Artificial intelligence is “an unstoppable force” that is being weaponized in ways that fall just short of traditional warfare, Britain’s cyberspying chief warned Wednesday. Anne Keast-Butler, director of the communications intelligence agency GCHQ, also said Britain and its allies are in “a space between peace and war” as Russia increases its “daily hybrid activity” against the West — even as Russian combat deaths in Ukraine approach 500,000. She said the West risks losing the conflict in cyberspace against Russia and other adversaries unless citizens, companies and governments treat cybersecurity with much greater urgency. “I’ve spent three decades working in national security, and the risk of miscalculation is as high as I’ve ever seen it,” Keast-Butler said in a speech at a World War II code-breaking center near London. She said that “tech companies are releasing AI-driven innovations at a remarkable pace, with untold consequences, as algorithms are weaponized often just below the threshold of traditional warfare. “AI is an unstoppable force with great opportunity,” she added. “But it is also a force with risks.” Keast-Butler singled out Russia as a threat, accusing Moscow of “relentlessly targeting critical infrastructure, democratic processes, supply chains and public trust” in Britain and Europe, as well as stealing technology and plotting sabotage and assassination attempts. “Russia is scaling up its daily hybrid activity against the U.K. and Europe, stretching from the seabed to cyberspace,” she told an audience of computing experts, diplomats, journalists and senior officials. “One area in sharp focus for us is protecting the data and energy flowing through the critical cables and pipelines in and around British waters,” she added. “We do this by exposing Russia’s intent, motive and underwater capabilities.” At the same time, she said Russian troops are “going backwards on the battlefield,” with new intelligence suggesting “almost half a million Russian soldiers” have been killed since the February 2022 invasion of Ukraine. The speech is the latest in a string of warnings from Western spies and intelligence experts that Russia is stepping up hostile activity in a “gray zone” that falls just below the threshold of war. In recent months, authorities in countries including Sweden, Poland, Denmark and Norway have alleged that hackers linked to Russia targeted their critical infrastructure, including power plants and dams. The head of the U.K.’s National Cyber Security Centre, Richard Horne, warned last month that hostile states including Russia, China and Iran are behind the most serious cyberattacks the country faces. He said such attacks could increase dramatically if Britain becomes involved in an international conflict. Keast-Butler said rapid advances in artificial intelligence mean that “the ground beneath our feet is shifting” and there is a “narrowing window for the U.K. and allies to stay ahead” of countries such as China, a science and technology “superpower.” She argued that there must be an effort “from boardrooms to living rooms” to make cybersecurity “10 times more urgent.” The spy chief said that GCHQ is developing a plan to “hardwire cutting-edge agentic AI into machine-speed cyber defense.” Harnessed responsibly, she said, AI can help spies “enhance algorithms, translate foreign languages, and find needles in haystacks quicker than ever before.” Keast-Butler also stressed the importance of international partnerships as U.S. President Donald Trump’s “America First” foreign policy and disregard for longtime allies strain the relationship between London and Washington. She said the U.K.-U.S. intelligence partnership is “fundamental for the security of both our nations.” GCHQ, short for Government Communications Headquarters, is the U.K.’s electronic and cyberintelligence agency. It works alongside the domestic security service MI5 and the foreign intelligence agency MI6. Keast-Butler, the first woman to head the agency, delivered the GCHQ director’s annual lecture speech at the agency’s World War II headquarters of Bletchley Park, a manor house 45 miles (72 kilometers) northwest of London where hundreds of mathematicians, cryptographers, crossword puzzlers, chess masters and other experts worked to crack Nazi Germany’s supposedly unbreakable secret codes. Their work both shortened the war and hastened the birth of modern computing.
securityweek.comMay 27, 2026extracted
The Credential Crisis: How Stolen Credentials Defeat Modern Security
Preventing credential compromise and surviving compromised credentials is not theoretically impossible but is difficult in practice and shows no sign of getting easier. Credentials The modern cyber use of the word ‘credentials’ stems from the Latin ‘creder’: to believe. As society evolved into the Middle Ages, the early notion of ‘Believe me. I am Socrates’ became, ‘Believe this physical letter that proves I am Socrates.’ Those physical letters became known as ‘credentialis’, or a paper that authenticated the bearer. In today’s cyber world, we call that paper ‘credentials. It is no longer physical, but virtual, and the meaning has expanded to ‘you can trust in the belief that I am who I say I am and you can treat me as such: I am Socrates.’ Socrates is the identity, and the credentials prove it. Cyber credentials In cyber today, credentials are largely categorized in two major groups: those for human identities, and those for machine and non-human identities. Human identity credentials can include passwords, passkeys, biometrics, soft and hardware tokens, and more. Non-human identities can include APIs, SSH keys, X.509 certificates, service accounts, session tokens and keys, and more. Session tokens require particular notice since a company may have 3,000 employees, but 300,000 active tokens; and session tokens are scraped by one of credentials’ common beta noirs – infostealers. It is worth remembering there are two stages: the theft of credentials is ‘credential compromise’, while a consequent breach is by ‘compromised credentials’. “Compromise does not necessarily mean the credentials have already been used. It means they are no longer exclusively controlled by the legitimate user,” explains Ran Geva, CEO and co-Founder at Webz.io. But they could be used. And by the nature of what they are, if used, they are automatically trusted as the legitimate user. “The defining trait,” adds Erin Meyers, identity expert at Huntress, “is that the attacker isn’t ‘breaking in’ the traditional way; they’re logging in (or reusing an already-authenticated session) and inheriting the [legitimate] user’s permissions, making malicious activity blend into normal access patterns.” From the system’s perspective, agrees Ariel Parnes, co-founder and COO at Mitiga, “the resulting activity appears authorized, making detection uniquely challenging.” Dan Schiappa, president of technology and services at Arctic Wolf, adds “Credential compromise is one of, if not the most useful and widespread, tactics of threat actors, since it can be carried out with minimal technical skill to gain easy access to target environments.” Sometimes, perhaps too often, the only credentials required are a username and password. In such cases, warns Bob Long, president for the Americas at Daon, “A single simple successful compromise can create a cascade of risk across multiple accounts, especially if the same credentials are reused.” Reinhard Hochrieser, SVP of product and technology at Jumio, warns that social security numbers (SSNs) and government issued IDs are also credentials. “Fraudsters use this data to carry out sophisticated attacks, which include the manipulation of those IDs and the creation of AI-generated deepfakes to bypass biometric checks… making smaller targets like everyday individuals more worthwhile to fraudsters.” Credential compromise, summarizes Jan Bee, CISO at TeamViewer, “allows attackers to bypass perimeter controls, evade detection, and operate inside trusted workflows. As a result, protecting infrastructure alone is no longer sufficient. Protecting identity continuously is now foundational.” Theft of credentials Before a breach can be caused by a compromised credential, the credential must first be acquired (stolen) by an attacker. We can and should make this as difficult as possible, but it is unlikely we will ever be able to prevent the theft of credentials. The primary cause is the traditional agility gap – the time gap between threat actors’ adoption of new techniques and security’s ability to adapt defenses to the new threat. AI provides an excellent example. Phishing remains the primary attack against individual credentials, but AI can produce compelling deepfakes with realistic backstories. There is no technology that can guarantee detection and prevention of this – it largely depends upon the human target’s personal risk tolerance and intuition. Torsten George, CMO at ID Dataweb, comments, “I recently got an email from the CEO. It wasn’t his usual email address, and the tone was a bit off. So, I sent him separately, via Teams, a screenshot of the email and asked him if he had sent it. He hadn’t.” If in doubt, double check. But an attacker doesn’t need to use technology – as Scattered Spider has illustrated. “Pretend to be a high ranking VP, five minutes away from a customer meeting, and you can no longer access your files. Call the Help Desk,” continues George. “That sort of pressure from a superior is often sufficient for the Help Desk person to effectively hand over the keys to the kingdom. This allows the attackers to move laterally until they find the crown jewels and exfiltrate them.” Whether phishing or scamming, it’s all based on social engineering that exploits human weaknesses. Meyers suggests a partial solution can be found in Identity Security Posture Management. “ISPM answers which identities are most likely to be compromised next? It tells you which credentials attackers will target – and why.” It’s not just individual credentials that are under threat. Schiappa comments, “According to our latest threat report, phishing attacks accounted for 85% of all incident responses. However, credential theft attacks can also occur via data exfiltration, infostealer malware and man-in the-the-middle attacks.” Infostealers remain a major threat against credentials. Once on a victim’s system, they scrape passwords (and much more) and send them back to the attacker. The X-Force 2025 Threat Intelligence Index (published February 25, 2026) states that in 400,000 tracked vulnerabilities, 56% required no authentication prior to exploitation. “So, we have attackers exploiting systems through remote code execution without authentication,” comments Michelle Alvarez, manager at X-Force Threat Intelligence. “Maybe they upload a file to a server that does not require authentication, and then boom, they’re in. So, no credentials needed, no MFA to bypass.” And potentially more credentials stolen. Knowing credentials have been compromised If we cannot prevent the theft of credentials, can we at least discover if they have been stolen and are available to bad actors? A stolen credential is an indicator that you could be attacked at any time. As with liberty, the cost of protection is eternal vigilance and is usually elusive. “There are companies that monitor the dark web for breach data and notify individuals if their information appears in exposed datasets, and while that can provide useful insight, it’s not something people can rely on completely,” says Long. “For consumers,” says Renee Burton, VP of threat intel at Infoblox, “one of the easiest ways to check is by using public breach notification services such as haveibeenpwned, where you can enter your email address and see if it has appeared in known data breaches. That can provide some visibility, but it is not a complete picture.” But Hochreiser warns, “Finding out if your credentials have been stolen is nearly impossible. If your email is compromised, you may get a notification, but when it comes to biometrics, there are no public services that can tell you whether or not that data got compromised in a breach.” Parnes suggests, “Use dedicated breach intelligence databases, including public repositories (such as ‘Have I Been Pwned’) and Dark Web Monitoring services (often offered by password managers and identity protection solutions that monitor ‘stealer logs’ – private marketplaces where hackers sell credentials before they ever hit public databases).” There is no simple, single solution. “Detection requires multiple approaches,” says Geva, noting breach dataset monitoring, dark web and marketplace monitoring, infostealer log intelligence, closed forum scraping, and Telegram channel monitoring. It was the complexity and time-consuming nature of monitoring all these sources for every credential loss that prompted Geva to launch the free to use lunarcyber.com (commonly known as Lunar) in late 2025. It does all the monitoring for you (constantly checking signs of compromise). “Lunar gives organizations early visibility into exposed credentials and identity artifacts, so they can act before attackers do,” he explains. “Lunar also includes advanced intelligence focused specifically on infostealer malware, which can indicate when company endpoints have been breached and when attackers have extracted high-value artifacts like session cookies and real-time username/password captures. This matters because even if a user changes their password, stolen sessions and tokens can remain valid and continue to provide access.” From credential compromise to compromised credential breach The basic problem remains: absence of proof is not proof of absence. “Credentials may be misused long before breach information is identified and communicated back to the affected individual. By the time a notification arrives, the attacker may already have exploited the access,” says Long. The first indication of credential compromise for most organizations is the discovery of a breach; but sometimes you can detect the attack before the actual breach. “Unauthorized password reset emails and ‘new login detected’ alerts are a clear signal that your credentials have been stolen,” warns Schiappa. MFA falls into a similar bracket, he continues. “MFA is a simple, effective access control that not only prevents a threat actor from gaining access via stolen credentials but can also serve as a mechanism to alert security teams that unusual login behavior is occurring.” But MFA is no longer perfect. George comments, “If you had asked me 18 months ago, I would have said it is a good deterrent. According to Microsoft, the bypass rate was 0.7% and therefore still within the limits. But today, the MFA bypass rate is in the low double-digit range, which poses a significant threat.” Stuart Sharp, VP of product at One Identity, adds, “Phishing-resistant MFA methods, like WebAuthn and Passkeys, incorporate two levels of protection – validating that the target website address is already known and not a spoofed variation of a valid site, and verifying that the authentication request is coming from a known, registered device. When combined with on-device biometric checks like face ID or fingerprints, these phishing resistant forms of MFA greatly reduce the risk of unauthorized access.” Roy Katmor, CEO at Orchid Security, adds, “MFA is highly effective against simple password replay, but it’s less effective against session theft, token replay, and MFA fatigue/push bombing (where attackers bombard users with prompts until one gets approved) unless it’s properly hardened. Phishing-resistant MFA is a meaningful step up and materially raises the bar.” But at the end of the day, adds George, “The human will always be the weakest link in the cyber attack chain, and that’s what many attackers exploit.” Regardless, “In many cases, people only realize their credentials have been compromised after something goes wrong, such as an unexpected password reset, an account lockout, or fraudulent charges on a credit card. Unfortunately, by the time those warning signs appear, the stolen credentials may already have been circulating or actively used by threat actors,” says Burton. When a compromised credential breach occurs, the game changes to one of early detection and rapid containment. Is there any defense against the use of stolen credentials once the attacker has achieved access? “Yes,” says Meyers, “but the defense shifts from preventing login to containing and outpacing the attacker.” This includes both detecting and slowing the attacker, resetting credentials to prevent further misuse, revocation of active sessions, and enforcing least privilege everywhere. “Once an attacker authenticates, the focus shifts from blocking access to detecting misuse and limiting blast radius,” agrees Bee. “The faster misuse is detected and contained, the smaller the impact.” The two best known tools for detection and containment are behavioral anomaly detection and zero trust principles. Behavioral detection Behavioral detection systems create a baseline of normal user behavior and are able to detect any deviation from that. That deviation is likely to indicate the presence of an intruder, even where access was enabled with valid credentials. “Once attackers authenticate, the giveaway becomes behavior,” says Meyers. Long describes it as continuous authentication. “Instead of trusting a user simply because they logged in successfully once, businesses can monitor behavior throughout the session. Techniques such as behavioral biometrics build a profile of how a customer normally interacts with a service. That can include where they typically are, the devices they use, how they handle that device, and their usual transaction patterns. If something falls outside that normal pattern, the system can step up security the next time the customer attempts an action.” Access, he says, should not be treated as a one-time decision. Bee agrees. “The real question is not whether the login was valid, but whether the behavior that follows aligns with expected identity patterns. If trust is granted once at login and maintained for the entire session, an attacker can operate freely within that window. That is why resilience depends on continuous validation, reassessing whether the user, device, and context remain consistent with what ‘normal’ looks like.” He continues, “Unusual access to new systems, privilege changes, or unfamiliar SaaS activity should trigger re-authentication, session isolation, or immediate revocation. In interconnected, SaaS-driven environments, speed is decisive. The faster misuse is detected and contained, the smaller the impact.” Zero trust Zero trust can assist in credential breach containment, but zero trust is still widely misunderstood as a product or technology. “Zero trust is not a technology. It’s not a product that you can buy off the shelf,” says George. “It is really a concept, a way of thinking; and it simply says, ‘Never trust anything, but rather double check everything’. In today’s dynamic threatscape, that’s an approach that every organization should apply. If you trust credentials, and you believe that a legitimate identity is behind it, you’re in the 70 plus percent of cases where you’re mistaken.” It’s that automatic trust that the attackers leverage. “If you never trust anything, but you really ask further questions, if you don’t automatically assume a credential equals an identity, but check it against things like geolocation, timing of the action, behavioral biometrics – if you can do that in the context of identities, then you’re really minimizing your risk exposure tremendously.” Carlos Aguilar Melchor, principal research scientist at SandboxAQ, agrees. “Zero Trust is a way of operating, not a finish line. The goal is simple: keep shrinking blast radius wherever identity and cryptography are well governed and enforced. “The old perimeter is gone,” he continues. “Keep moving to continuous verification across users, devices, services, data, and agents. Make every transaction check policy, and treat identity as the control plane for both people and machines.” While zero trust is neither a product nor a finish line, “Partial zero trust is still worth doing if you can measure it,” he suggests. “Start with phishing-resistant MFA, signed software and models, workload identity, and service-to-service mutual Transport Layer Security (mTLS). Keep crypto strong so machine identities stay trustworthy.” It is the continuous verification that is important, says Meyers. “Zero trust is strong against ‘credential = keys to the kingdom’ thinking, because it emphasizes continuous verification and conditional access. Most notably, zero trust shines when paired with enforcement that catches trust boundary violations and limits lateral movement after initial access.” Microsegmentation, often considered to be a key aspect in implementing the zero trust concept, is a strategy rather than a technology. It is useful in containing an intruder. “It limits the ‘blast radius’ by ensuring one compromised account cannot move freely across the entire network,” comments Parnes. ‘Freely’ is the key word. It doesn’t prevent lateral movement, but it slows it down. That alone could be enough. Cybercriminals don’t like to hang around, which could lead to exposure and unintended consequences. If things get tough, they are quite likely to leave and move on to the next victim. The agility gap in action One thing we haven’t mentioned but really should, is the effect of stolen API keys for agentic AI systems. The speed of full compromise and the potential blast radius are both increased exponentially, and the threat surface (the use of agentic AI systems within and by business) is expanding dramatically. It is another example of AI expanding the agility gap. This API key isn’t simply capable of unlocking the data store, it is the key to an agent who is effectively a trusted employee able to talk to other similarly trusted employees, roam freely through the network and act autonomously. It has access beyond datasets into workflows. Since agents are necessarily trusted by the system, they are unlikely to trip any detection mechanism or be delayed by firewalls until after it or they act. Once into the agentic system, the attacker effectively has access to every system or platform (Jira, Slack, AWS, etcetera) the agentic system integrates with. Such an attacker, unlikely to be detected, could explore possibilities available through the agentic system, and then strike. This strike could include thousands of malicious actions at machine speed across the victim’s entire infrastructure before it is detected. With stolen API keys, possible detection and containment is low, and blast radius is high. The future “I think, quite frankly, as with any type of attack, the threat actors will always be a step ahead of us,” says George. “It is our task to reduce the agility gap between the attacker and defender as far as possible, but we will never eliminate it. We will never be able to completely protect against any attack, including against identity-based attacks. And to any vendor or professional that claims 100% protection… you should laugh at them.” Related: Autonomous AI Agents Provide New Class of Supply Chain Attack Related: Cybercriminals Trade 183 Million Stolen Credentials on Telegram, Dark Forums Related: The Wild West of Agentic AI – An Attack Surface CISOs Can’t Afford to Ignore Related: Cyber Insights 2026: Zero Trust and Following the Path Related: 136 NPM Packages Delivering Infostealers Downloaded 100,000 Times
securityweek.comMay 27, 2026extracted
Loading 40 more…