What resonated most at RWC 2026? GitGuardian highlights key research on private key leaks, password managers, trusted execution environments, and secret sprawl.
The post Key Leaks, Vault Failures, and TEE Attacks: Highlights from RWC 2026 appeared first on Security Boulevard.
Most teams govern AI workloads at the application layer. They configure guardrails for their Bedrock agents, scope IAM roles per workload, and build policies around approved models. That discipline matters, but it breaks down the moment a developer spins up a new account or invokes a model directly without touching the application stack. Org-level enforcement […]
The post 5 AWS AI Controls Every Security Team Should Have appeared first on Security Boulevard.
New research maps the full infostealer lifecycle. Your credentials go from an employee’s device to an underground marketplace in less time than it takes your security team to notice anything is wrong. On March 24, 2026, researchers at Whiteintel’s Intelligence Division published a detailed map of the full infostealer lifecycle, tracing the exact sequence from […]
The post 48 Hours: The Window Between Infostealer Infection and Dark Web Sale appeared first on Security Boulevard.
Author, Creator & Presenter: Kody Lundell, CEH - Senior Security Engineer at Podium
Our thanks to BSidesSLC for publishing their Creators, Authors and Presenter’s outstanding BSidesSLC 2025 content on the Organizations' YouTube Channel.
The post BSidesSLC 2025 – Cybersecurity At Home – Protecting Your Family In A Connected World appeared first on Security Boulevard.
The Iranian government is threatening to attack the Middle East operations of more than a dozen U.S. tech companies, including Microsoft, Nvidia, and Google, calling them "legitimate targets." Meanwhile, pro-Iranian threat groups expand their operations as the U.S. and Israel continues their bombing campaign against Iran.
The post Iran Calls U.S. Tech Companies ‘Legitimate Targets,’ Threatens to Attack appeared first on Security Boulevard.
Learn how to secure Model Context Protocol (MCP) deployments using granular policy engines and post-quantum cryptography to prevent AI tool poisoning and puppet attacks.
The post Granular Policy Enforcement Engines for Post-Quantum MCP Governance appeared first on Security Boulevard.
How Secure Are Your Non-Human Identities (NHIs)? With cyber threats evolving, have you considered how effectively you are managing your Non-Human Identities (NHIs)? This crucial aspect of cybersecurity often flies under the radar, overshadowed by more traditional concerns. However, where reliance on cloud services grows, ensuring robust NHI management is not just recommended—it’s essential. Understanding […]
The post Are you satisfied with your current NHI management? appeared first on Entro.
The post Are you satisfied with your current NHI management? appeared first on Security Boulevard.
How Do Non-Human Identities Elevate Cybersecurity Strategies? Evolving cybersecurity demands innovative approaches to safeguard digital assets, and Non-Human Identities (NHIs) are at the forefront of this transformation. But what exactly are NHIs, and how do they fit into the broader context of cybersecurity, particularly in cloud environments? NHIs represent machine identities used within cybersecurity frameworks. […]
The post What makes Agentic AI a powerful ally in cybersecurity? appeared first on Entro.
The post What makes Agentic AI a powerful ally in cybersecurity? appeared first on Security Boulevard.
How Do Non-Human Identities Revolutionize Cloud Security? Have you ever wondered about the hidden complexities lurking behind cloud security? Organizations are increasingly reliant on cloud-based solutions, and one of the most innovative strategies to bolster security is through effective management of Non-Human Identities (NHIs). These NHIs are crucial players in cybersecurity, particularly when dealing with […]
The post Why be optimistic about the future of Agentic AI? appeared first on Entro.
The post Why be optimistic about the future of Agentic AI? appeared first on Security Boulevard.
[CRITICAL] | Active RAT | Malicious npm versions removed | Assess all systems that ran npm install during exposure window
The post Technical Advisory: Axios npm Supply Chain Attack – Cross-Platform RAT Deployed via Compromised Maintainer Account appeared first on Security Boulevard.
A newly discovered software supply chain attack targeting the npm ecosystem briefly compromised one of the most widely used JavaScript libraries in the world.
The post Axios Compromise on npm Introduces Hidden Malicious Package appeared first on Security Boulevard.
The cybersecurity industry has long grappled with a significant representation gap, but a new documentary premiering at RSAC 2026 is working to change the conversation. In this interview from Broadcast Alley, Techstrong Group’s Jon Swartz speaks with Aarti Gadhia and Kristen Rank about The Women in Security, a film five years in the making and..
The post Flipping the Script: The Premiere of ‘The Women in Security’ Documentary at RSAC appeared first on Security Boulevard.
We used Tonic Fabricate to generate a fully synthetic email corpus, then RL fine-tuned an open-source model against it. The result: it beat o3 on real Enron emails — without ever seeing a real email.
The post Synthetic data is all you need for Reinforcement Learning appeared first on Security Boulevard.
Alan Shimel sits down with longtime friend and cybersecurity veteran Rich Mogull to discuss his new role as chief analyst at the Cloud Security Alliance. The conversation covers a lot of ground, from the rapid rise of agentic AI to how CSA is working to bridge the gap between high-level security frameworks and the practitioners..
The post Bridging the Gap: CSA’s AI Security Initiatives at RSAC appeared first on Security Boulevard.
The post When AI Writes the Code, What Changes for Security? appeared first on Security Boulevard.
Introduction Xloader is an information stealing malware family that evolved from Formbook and targets web browsers, email clients, and File Transfer Protocol (FTP) applications. Additionally, Xloader may execute arbitrary commands and download second-stage payloads on an infected system. The author of Xloader continues to update the codebase, with the most recent observed version being 8.7. Since version 8.1, the Xloader developer applied several changes to the code obfuscation. The purpose of this blog is to describe the latest obfuscation methods and provide an in-depth analysis of the network communication protocol. We highly recommend reading our previous blogs about Xloader in order to get a better understanding of the malware’s internals.Key TakeawaysFormbook is an information stealer that was introduced in 2016 and rebranded as Xloader in early 2020. The malware continually receives enhancements, with the latest version being 8.7.Xloader version 8.1 introduced additional code obfuscation to make automation and analysis more difficult.Xloader supports a variety of network commands that may be used to deploy second-stage malware payloads.Xloader adds multiple encryption layers to protect network communications and leverages decoys to mask the actual malicious C2 servers.Technical AnalysisIn the following sections, ThreatLabz describes the key code updates introduced in Xloader from version 8.1 onward and the current network communication protocol. It is important to note that Xloader is a rebranded version of FormBook. Therefore, many parts of Xloader contain tangled legacy code that is not used.Code obfuscationThroughout Xloader’s development, the authors have used obfuscation at different stages of execution, such as:Encrypted strings that are decrypted at runtime.Encrypted code blocks consisting of functions that are decrypted at runtime and re-encrypted after execution.Opaque predicates in combination with bitwise XOR operations to decrypt integer values.Xloader still relies on the obfuscated methods listed above with some additional modifications, which are described below.Functions decryption routineAs previously documented, Xloader detects and decrypts each necessary function at runtime. This process involves constructing and decrypting two “eggs”, which mark the start and end of the encrypted function data. The function responsible for decrypting the encrypted functions at runtime has its parameters constructed on the stack. Starting with version 8.1, Xloader builds each parameter without following a specific order and, in some cases, builds each parameter byte by byte.The figure below shows an example of Xloader constructing the eggs prior to version 8.1 (top) with a consistent size and ordering, compared to the latest versions of Xloader (bottom) constructing the egg parameters out of order with varying chunk sizes before calling the decrypt function.Figure 1: Comparison of Xloader egg construction for function decryption.Even though these changes may seem minor, they have a significant impact on automation tooling. Since the order of the encrypted starting and ending arrays are no longer set, the function’s memory layout needs to be reconstructed properly to perform analysis and extract values, as typical pattern matching would not be able to assist. As a result, extracting these values at an assembly level becomes a tedious task. One tool that can be used when analyzing these changes is the Miasm framework, which can statically lift the obfuscated code and reconstruct the stack properly.Code obfuscation and opaque predicatesStarting with version 8.1, Xloader introduced more sophisticated obfuscation for hardcoded values and specific functions. Constant value obfuscation was present in previous versions of Xloader, but it was employed in much simpler cases. An example of an early, simpler constant obfuscation routine is shown below.var1 = 190;
// Sets var1 memory pointer to 0
erase_data_if(&var1, sizeof(var1));
if ( var1 == 0x91529F54 )
out = 0; // Never executed
else
out = (out + 0x6EAD60AC) ^ 0x6C69DE1C; // result: 0x02c4beb0In the latest versions, Xloader encrypts additional constant values. For instance, when adding the typical assembly function prologue bytes (followed by a series of NOP instructions) for a decrypted function, Xloader now decodes the prologue bytes using a bitwise XOR operation, as shown in the figure below.Figure 2: An example of Xloader’s function prologue bytes obfuscation.In addition to the enhancements described above, the custom decryption routine that Xloader uses to decrypt data is now obfuscated. The unobfuscated custom decryption function prior to version 8.1 is shown below.Figure 3: Xloader’s custom decryption routine prior to version 8.1.In the latest versions, Xloader passes a structure parameter that includes hardcoded values. The obfuscated function reads each required structure member and decrypts each value. In the figure below, Xloader decrypts the Substitution Box (S-box) size by reading the value 0x25 from the structure passed to the function and adds 0xDB (line 39 in the decompiled obfuscated function shown in the figure below).Figure 4: Xloader’s obfuscated custom decryption routine since version 8.1.Network communicationAt a high level, Xloader has two main objectives. First, to exfiltrate user credentials and sensitive information from the compromised host. These include passwords and cookies from various software applications such as internet browsers (e.g. Google Chrome) and email clients (e.g. Microsoft Outlook). Second, to execute arbitrary commands including downloading and executing additional payloads. In this section, we examine how Xloader performs these network-based actions.Network protocol and encryptionXloader has two methods for sending an HTTP request to the C2 that produce the same network traffic output but with a different User-Agent HTTP header. Depending on a pre-configured boolean flag, Xloader uses: Raw TCP sockets where the User-Agent may vary from sample to sample and tries to mimic common browser User-Agent values.WinINet API functions (e.g. HttpSendRequest) where the User-Agent is set to Windows Explorer and is the same across all samples.For raw TCP sockets, Xloader confirms that the Windows API function gethostbyname is not inline-hooked by comparing the first byte of the API function with the following values.0xE9 - Near JMP instruction.0xEA - Far JMP instruction.0xCC - INT3 instruction.If there is a hook detected, Xloader does not send the HTTP request. There are two primary threads for network communication:In all cases, the first thread is used to prepare exfiltrated data and encrypt any outgoing network packets. If the boolean flag for raw TCP sockets is true, Xloader uses this thread to send the exfiltrated data and request commands.Otherwise, a second thread is used to send HTTP requests with the WinINet API functions.Internally, Xloader’s code uses request IDs for C2 communication, which are described in the table below.Internal Request IDDescription3HTTP POST requests sent to the C2 server containing exfiltrated credentials.6HTTP GET requests sent to the C2 server containing PKT2 messages.Table 1: Xloader internal request IDs.ANALYST NOTE: Despite not being used, Xloader does support a set of additional internal request IDs. These are 7, 8, 9, 10, and 12. ThreatLabz believes that the additional request IDs are part of legacy code.Despite using plaintext HTTP requests for network communication, Xloader uses a combination of multiple encryption layers with different keys for encrypting network traffic as shown in the table below.RC4 Key NameInternal Request ID(s)DescriptionFirst PKT2 RC4 key6Encrypts PKT2 data (described below).Second PKT2 RC4 key6Encrypts the full PKT2 data, which includes the magic header XLNG.HTTP GET packets RC4 key6Encrypts all HTTP GET requests before sending them. Xloader only uses this key for the outgoing PKT2 data.C2 URL key3 and 6Encrypts the message with the SHA1 hash of the C2 URL.C2 URL RC4 seed 3 and 6Xloader uses these seed values to derive new keys based on the C2 URL to encrypt/decrypt network data. Xloader deliberately decrypts the key at different execution phases in an attempt to complicate analysis.Table 2: Summary of Xloader network communication encryption layers.Network encryption for Xloader versions 8.1 and onward is similar to recent versions. Xloader uses a set of decoy C2 servers to mask the real malicious C2 servers. Xloader includes a total of 65 C2 IP addresses that are individually decrypted only when they are used at runtime. Xloader randomly chooses 16 C2 IP addresses and starts sending HTTP requests (both internal request IDs 3 and 6 mentioned in Table 1). Xloader repeats this process until all C2 servers have been contacted. This makes it difficult for malware sandboxes to differentiate decoys from the real C2 servers. Thus, the only way to determine the real C2 servers is to first establish a network connection with each C2 address (e.g. by network emulation) and verify the response.ANALYST NOTE: For the rest of the blog, encryption/decryption refers to the RC4 cipher algorithm and encoding/decoding refers to the Base64-encoding algorithm, unless otherwise specified.As mentioned above, Xloader sends an HTTP GET request to the C2 server to retrieve a network command. The packet contains the following information.A magic header set to XLNG.A 8-byte hexadecimal string, which is the bot ID.Xloader version in a string format (e.g. 8.5).Windows version (e.g. Windows 10 Pro x64).Hostname and username in Base64-encoded format.Xloaders encrypts the packet using the first PKT2 RC4 key and then encodes the packet. Next, Xloader prepends the string PKT2: to the encoded packet and encrypts it using the second PKT2 RC4 key.Xloader has a dedicated function to prepare network data before sending it to the C2. Depending on the request type (Table 1), Xloader uses a different encryption chain and set of HTTP headers. For HTTP GET requests, Xloader encrypts the network data in the order outlined below. Xloader uses a hardcoded RC4 key for the first encryption layer.Xloader encrypts the data by using the SHA-1 hash of the C2 URL as a key.Xloader derives a new RC4 key by decrypting the C2 URL network seed with the SHA-1 hash of the C2 URL as a key. The decryption algorithm is custom and has already been documented. Xloader uses the derived key to encrypt the network data.As a final step, Xloader encodes the encrypted data and prepends the hardcoded string &dat=, even though this string value is stripped (and therefore not sent).Xloader uses HTTP GET requests solely for PKT2 requests. Notably, the RC4 key of the first encryption layer is the same as the key used when preparing the PKT2 packet. As a result, this layer of encryption does not make any meaningful changes in the final output of the network data. ThreatLabz has observed this behaviour across all samples since at least version 7.9.ANALYST NOTE: When Xloader uses high level Windows API functions (e.g. HttpSendRequest) instead of raw sockets for network communication, the Base64-encoded data includes the parameter query &wn=1 at the end.Lastly, Xloader generates two random alphanumeric query parameter names that are placed in the generated GET request URI. One of them is used for the encoded data value. The size ranges of the parameter names change per sample. The position of the data’s query parameter is randomly selected (based on a flag deduced from the victim’s’s system time) and can be placed at the start or end of the URI. For example: {random_parameter1}={encoded_data}&{random_parameter2}={random_parameter2_junk_data}.Additionally, Xloader collects credentials and cookies from the victim’s system. Xloader sends the stolen data using HTTP POST requests. The encryption process and data structure remain mostly the same but with some minor differences as described below: Xloader does not use the hardcoded RC4 key for encryption and completely ignores this encryption layer. Instead, Xloader encrypts the data using the SHA-1 hash of the C2 URL as a key followed by a secondary encryption layer with a key derived from the C2 URL seed.Xloader proceeds to encode the data. However, the characters “+”, “/” and “=” are replaced with “-”, “_”, and “.”, respectively.Xloader repeats the same encryption process described in the previous steps.The data resulting from the previous operation is encoded (without modifying the output this time).Xloader uses a different format for the constructed POST request data. In this case, the format is “dat=” + final_base64_encoded_data + "&un=" + base64_encoded_host_info + "&br=9”.Network commandsXloader receives and parses network command packets only after sending HTTP GET requests. After a response is received, Xloader internally constructs a data structure that includes the data received and its size, along with the corresponding RC4 decryption key, as shown below.struct parsed_network_packet
{
uint32_t packet_flag_marker; // Set to 1 after reading all network data.
uint32_t sizeof_data; // Total size of network data received.
uint8_t packet_rc4_key[20]; // RC4 key for decrypting the network data.
uint32_t unknown;
uint8_t* data;
};Similar to the outgoing network packets, Xloader uses the SHA-1 hash of the C2 URL as an RC4 key in order to derive a second key from the C2 URL network seed. Next, Xloader decodes the network data and decrypts it twice with two different keys. In the first instance, Xloader uses the SHA-1 hash of the C2 URL as an RC4 key, while in the second case Xloader uses the derived RC4 key. The decrypted packet contains a network command ID to execute and parameters (if any). The data structure for Xloader’s commands is shown below.#pragma pack(1)
struct command_packet
{
char magic[4]; // Set to XLNG
char cmd_id;
char* command_data;
};ANALYST NOTE: When Xloader uses the high level WinINet functions, it checks if the currently chosen C2 index matches a hardcoded value (e.g. 9). If there is a match, Xloader uses the SHA-1 hash of the C2 URL as an RC4 key. If there isn’t a match, Xloader leaves the field empty causing the decryption of any network packets to fail. However, when using Windows raw TCP sockets, Xloader uses that RC4 key without performing any further checks.The table below shows Xloader’s network commands.Command IDDescription1Executes one of the following file types.PowerShell script.Windows executable (EXE) file.Windows DLL file.2Updates Xloader.3Xloader removes itself from the compromised host.4Depending on the command parameter field, Xloader performs one of the following actions.If the parameter is RMTD, then Xloader downloads and executes a PowerShell script. The payload location is specified in the network command packet. For example: XLNG4RMTD:https://payload_url/payload.ps1XLNG.If the parameter is RMTU, then Xloader downloads and executes a Windows executable (EXE) file. Similarly, the remote location of the payload is included in the network packet. For example: XLNG4RMTU:https://payload_url/payload.binXLNG.If no parameters are passed, then Xloader executes the file specified in the command parameter. For example: XLNG4C:\\payload.exeXLNG.5Remove browser cookies.6Invokes Xloader’s credential stealing capabilities.7Reboots the compromised host.8Shuts down the compromised host.9Not implemented. Across all samples, the functionality of this command corresponds to a function with the assembly instructions XOR EAX,EAX and RET.Table 3: Xloader’s network commands.ConclusionXloader continues to be a highly active information stealer that constantly receives updates. As a result of the malware’s multiple encryption layers, decoy C2 servers, and robust code obfuscation, Xloader has been able to remain largely under the radar. Therefore, ThreatLabz expects Xloader to continue to pose a significant threat for the foreseeable future.Zscaler CoverageZscaler’s multilayered cloud security platform detects indicators related to Xloader at various levels. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for Xloader.Figure 5: Zscaler Cloud Sandbox report for Xloader.In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to Xloader at various levels with the following threat names:Win32.PWS.XloaderIndicators Of Compromise (IOCs)SHA256 HashDescription316fee57d6004b1838576bb178215c99b56a0bd37a012e8650cd2898041f6785Xloader version 8.759db173fbff74cdab24995a0d3669dabf6b09f7332a0128d4faa68ae2526d39aXloader version 8.56b15d702539c47fd54a63bda4d309e06d3c0b92d150f61c0b8b65eae787680beXloader version 8.5
The post Latest Xloader Obfuscation Methods and Network Protocol appeared first on Security Boulevard.
Mar 31, 2026 - Jeremy Snyder - If you were at RSA Conference last year, you probably remember the goats. Or the puppies. Or the miniature petting zoos. It was a year of "over-the-top" spectacle. A bit of a circus, if I’m being honest.Coming into RSAC 2026, the vibe shifted. The show floor was noticeably more subdued, and frankly, I welcomed it. The industry seems to have traded the gimmicks for a renewed focus on actual business outcomes.That’s not to say it was boring. We saw a wrestling ring on the floor, and one particularly creative vendor bought two booths just so one could literally be a giant pointer to the other. But the real "main event" wasn’t the marketing theater; it was the quiet, intense innovation happening in the corners of the Moscone Center.The Return of Substance (and the Early Stage Expo)One of my personal highlights was the Early Stage Expo. It wasn’t just interesting because FireTail was in the mix, but because of the way founders are reimagining "old" strategies for "new" problems.I saw companies building EDR (Endpoint Detection and Response) specifically for AI agents. It’s a fascinating application of a proven cybersecurity strategy to a brand-new attack surface. We also saw a resurgence in "stagnant" categories; new vulnerability management and CSPM (Cloud Security Posture Management) vendors are emerging, proving that even the most established spaces still have room for disruption when the underlying technology (like AI) shifts the landscape.The Collaboration Paradox: Rhetoric vs. RealityOne thing that still bugs me, however, is what I call the Collaboration Paradox.The RSA stage is always full of talks about "sharing intelligence" and "working together." But on the floor? It’s a different story. As vendors, we see the most compelling signals. We see how AI agents are being abused and what specific attack vectors are hitting different surfaces.Yet, we largely keep that data to ourselves to maintain a competitive advantage. While customers have formed great ISACs (Information Sharing and Analysis Centers), the vendor community is still falling short of the collaboration we publicly champion. We have the data to make everyone safer; we just need the collective will to share it.The Great AI Split: 50/50Walking the floor, it was clear that every single booth was talking about AI. But look closer, and you’ll see a 50/50 split in the market:Securing AI: Building the guardrails and controls for AI systems.AI in Security: Using LLMs and agents to make traditional security tools faster and smarter.FireTail lives right at the heart of this intersection. As we move from "AI hype" to "AI implementation," the question isn't just "Can we use AI?" but "Is our AI posture actually secure?"Watch: The 5 Layers of AI SecurityDuring the conference, I had the opportunity to dive deep into this topic. My talk, "The 5 Layers of AI Security," focuses on moving past the buzzwords to a functional framework for protecting the modern AI stack.We cover everything from the model layer to the prompt and data layers, ensuring that as you deploy these agents, you aren't inadvertently opening a back door to your most sensitive data.It was an exhausting, long week. My feet still hurt. But every year, RSAC reminds me why we do this.I saw friends I’ve known for decades who are still as engaged and mission-driven as they were on day one. Despite the "data hoarding" by vendors, the people in this industry genuinely want to help their customers achieve better outcomes.We’re at a pivot point in cybersecurity. The spectacle is over; the real work of securing the AI-driven enterprise has begun. See you at the next one!
The post Beyond the Spectacle – RSAC 2026 and The 5 Layers of AI Security – FireTail Blog appeared first on Security Boulevard.
Author, Creator & Presenter: Chris Beckman - Principal Security Engineer at TaxBit
Our thanks to BSidesSLC for publishing their Creators, Authors and Presenter’s outstanding BSidesSLC 2025 content on the Organizations' YouTube Channel.
The post BSidesSLC 2025 – Considering Cloud Coverage In SIEM/XDR Design appeared first on Security Boulevard.
Developers using the axios package from npm may have downloaded a malicous version that drops a Remote Access Trojan
The post Axios supply chain attack chops away at npm trust appeared first on Security Boulevard.
The post <b>Synthetic Data and GDPR Compliance</b> appeared first on Sovy.
The post Synthetic Data and GDPR Compliance appeared first on Security Boulevard.
