Category Archives: Windows

Zoom client for Windows could allow hackers to steal users’Windows password

The popular Zoom app is under scrutiny, experts have discovered a vulnerability that could be exploited to steal users’ Windows passwords.

Experts warn of a ‘UNC path injection’ flaw that could be exploited by remote attackers to steal login credentials from Windows systems.

Security experts and privacy advocates believe that the Zoom is an efficient online video communication platform, but evidently it has some serious privacy and security solutions.

The first expert to warn about the security flaw goes online with the handle Mitch (@_g0dmode).

The popular researchers Matthew Hickey (aka Hacker Fantastic) and Mohamed A. Baset also confirmed the existence of the flaw.

The latter also created a simple demo of the Zoom UNC path injection issue

The attack leverages the SMBRelay technique that provides username and NTLM password hashes to a remote SMB server when connecting to it.

The Zoom client for Windows supports remote Universal Naming Convention (UNC) paths and converts URLs into hyperlinks for recipients in a chat.

An attacker could steal the login credentials of a Zoom Windows user, by sending a crafted URL (i.e. \\x.x.x.x\zyz) to the victim via chat and trick the victim into clicking it.

The attack could allow capturing the hashed passwords that could be cracked using specific tools like John the Ripper.

The experts reported the issue to Zoom, but the vulnerability has yet to be fixed.

In January, experts discovered another flaw in the popular video conferencing software that could be exploited to join meetings and view all content shared by participants.

The issue allowed anyone to remotely eavesdrop on unprotected active meetings, potentially exposing private audio, video, and documents shared throughout the session.

Pierluigi Paganini

(SecurityAffairs – video communication, hacking)

[adrotate banner=”13″]

The post Zoom client for Windows could allow hackers to steal users’Windows password appeared first on Security Affairs.

Experts published PoC exploits for CVE-2020-0796 privilege escalation flaw on Windows

Researchers published proof-of-concept (PoC) exploits for the CVE-2020-0796 Windows flaw, tracked as SMBGhost, that can be exploited for local privilege escalation.

Researchers Daniel García Gutiérrez (@danigargu) and Manuel Blanco Parajón (@dialluvioso_) have published proof-of-concept (PoC) exploits for the CVE-2020-0796 Windows vulnerability, tracked as SMBGhost, that can be exploited by attackers for local privilege escalation.

Cybersecurity firms Kryptos Logic discovered roughly 48,000 servers vulnerable to SMBGhost attacks exposed online.

On March 12, Microsoft released security updates to address the CVE-2020-0796 vulnerability in SMBv3 protocol that could be exploited by vxers to implement “wormable” malware.

On March 10, 2019, the IT giant accidentally leaked info on a security update for a wormable vulnerability in the Microsoft Server Message Block (SMB) protocol.

The issue is a pre-remote code execution flaw that resides in the Server Message Block 3.0 (SMBv3) network communication protocol.

Technical details of the CVE-2020-0796 vulnerability have been disclosed, but security firms Cisco Talos and Fortinet published a description of the issue on their websites.

The vulnerability is caused by an error in the way SMBv3 handles maliciously crafted compressed data packets, a remote, unauthenticated attacker could exploit the flaw to execute arbitrary code within the context of the application.

The CVE-2020-0796 vulnerability affects devices running Windows 10 Version 1903, Windows Server Version 1903 (Server Core installation), Windows 10 Version 1909, and Windows Server Version 1909 (Server Core installation). According to Fortinet other Microsoft versions should be affected.

Microsoft released the KB4551762 update for Windows 10, versions 1903 and 1909, and Windows Server 2019, versions 1903 and 1909.

Immediately after the disclosure of the flaw, security experts created PoC exploits to trigger DoS condition, but now cybersecurity firm ZecOps published technical details of the flaw and released a PoC for remote code execution. The PoC exploits could be exploited to escalate privileges to SYSTEM.

“The bug is an integer overflow bug that happens in the Srv2DecompressData function in the srv2.sys SMB server driver.” wrote the experts. “We managed to demonstrate that the CVE-2020-0796 vulnerability can be exploited for local privilege escalation. Note that our exploit is limited for medium integrity level, since it relies on API calls that are unavailable in a lower integrity level.”

Pierluigi Paganini

(SecurityAffairs – hacking, CVE-2020-0796)

The post Experts published PoC exploits for CVE-2020-0796 privilege escalation flaw on Windows appeared first on Security Affairs.

0patch releases free unofficial patches for Windows 0days exploited in the wild

ACROS Security’s 0patch service released unofficial patches for two Windows flaws actively exploited by attackers in the wild.

ACROS Security’s 0patch service released unofficial patches for two Windows vulnerabilities actively exploited by attackers in the wild, both issues have yet to be fixed by Microsoft.

A few days ago, Microsoft warned of hackers actively exploiting two zero-day remote code execution vulnerabilities in Windows Adobe Type Manager Library. Both issues impact all supported versions of Windows.

The vulnerabilities affects the way Windows Adobe Type Manager Library handles a specially-crafted multi-master font – Adobe Type 1 PostScript format.

“Microsoft is aware of limited targeted attacks that could leverage un-patched vulnerabilities in the Adobe Type Manager Library, and is providing the following guidance to help reduce customer risk until the security update is released.” reads the advisory published by Microsoft.

“Two remote code execution vulnerabilities exist in Microsoft Windows when the Windows Adobe Type Manager Library improperly handles a specially-crafted multi-master font – Adobe Type 1 PostScript format.”

Microsoft announced that it plans to address the flaws with the release of the next month’s Patch Tuesday scheduled on April 14.

Microsoft pointed out that a successful attack on systems running supported versions of Windows 10 could only result in code execution within an AppContainer sandbox context with limited privileges and capabilities.

Microsoft described multiple attack scenarios, the attackers could trick victims into opening a specially crafted document or viewing it in the Windows Preview pane. The vulnerabilities could not be exploited through Internet Explorer or the Outlook preview pane.

The flaws impact all supported versions of Windows.

Microsoft pointed out that a successful attack on systems running supported versions of Windows 10 could only result in code execution within an AppContainer sandbox context with limited privileges and capabilities.

Microsoft suggests disabling the Preview Pane and Details Pane in Windows Explorer to mitigate the risk of exploitation of both zero-day flaws. Another mitigation consists of disabling the WebClient service, it allows to block the most likely remote attack vector through the Web Distributed Authoring and Versioning (WebDAV) client service. Another workaround is renaming the actual library ‘ATMFD.DLL.’

Waiting for the official patches, 0patch developed an unofficial patch and will release it for free, Once the official patches will be released by Microsoft, the 0patch fix will be available to its paying customers.

The security patches developed by 0patch address the issues for Windows 7 and Windows Server 2008 R2 without ESU. The service will also release unofficial patches for Windows 7 and Server 2008 R2 with ESU, Windows 8.1, and Windows Server 2012.

“With this micropatch in place, all applications using Windows GDI for font-related operations will find any Adobe Type 1 PostScript fonts rendered invalid and unable to load,” reads a post containing technical details of the patches released by 0patch.

Below a video published by the experts that shows the micropatch in action:

Pierluigi Paganini

(SecurityAffairs – Windows patches, zero-days)

The post 0patch releases free unofficial patches for Windows 0days exploited in the wild appeared first on Security Affairs.

Micropatches block exploitation of Windows zero-days under attack

While we wait for Microsoft to provide fixes for the two new Windows RCE zero-days that are being exploited in “limited targeted Windows 7 based attacks,” ACROS Security has released micropatches that can prevent remote attackers from exploiting the flaws. About the micropatches for Windows zero-days In a blog post published on Thursday, ACROS Security CEO Mitja Kolsek explained which attack vectors can be used to exploit the vulnerabilities and why Windows 10 users are … More

The post Micropatches block exploitation of Windows zero-days under attack appeared first on Help Net Security.

Windows users under attack via two new RCE zero-days

Attackers are exploiting two new zero-days in the Windows Adobe Type Manager Library to achieve remote code execution on targeted Windows systems, Microsoft warns. The attacks are limited and targeted, the company noted, and provided workarounds to help reduce customer risk until a fix is developed and released. More about the new Windows zero-days According to the security advisory published on Monday, the vulnerabilities arise from the affected library’s improper handling of a specially-crafted multi-master … More

The post Windows users under attack via two new RCE zero-days appeared first on Help Net Security.

Pwn2Own 2020 Day1 -researchers earned $180K for hacking Windows, Ubuntu, and macOS

During the first day of the Pwn2Own 2020 hacking competition, participants earned a total of $180,000 for exploits targeting Windows 10, Ubuntu Desktop and macOS.

The Coronavirus outbreak hasn’t stopped the Pwn2Own hacking conference, for the first time its organizer, the Zero Day Initiative (ZDI), has decided to arrange the event allowing the participants to remotely demonstrate their exploits.

On the first day of Pwn2Own 2020, a team from the Georgia Tech Systems Software & Security Lab (@SSLab_Gatech) successfully exploited a kernel privilege escalation to execute code on macOS through Safari. The attack chain involved six vulnerabilities and allowed the team to earn $70,000.

“1000 – The Georgia Tech Systems Software & Security Lab (@SSLab_Gatech) team of Yong Hwi Jin (@jinmo123), Jungwon Lim (@setuid0x0_), and Insu Yun (@insu_yun_en) targeting Apple Safari with a macOS kernel escalation of privilege.” reads the official page of the event.

SUCCESS – The team from Georgia Tech used a six bug chain to pop calc and escalate to root. They earn $70,000 USD and 7 Master of Pwn points.”

The popular Team Fluoroacetate (Amat Cama and Richard Zhu) that won past editions, earned $40,000 for a local privilege escalation exploit targeting Windows 10. Zhu also earned another $40,000 for another privilege escalation exploit targeting Windows 10.

Manfred Paul of the RedRocket CTF team earned $30,000 for a local privilege escalation exploit targeting Ubuntu Desktop. The hack exploits an improper input validation bug.

On the second day of Pwn2Own 2020, participants will attempt to hack Oracle VirtualBox, VMware Workstation and Adobe Reader.

Below the schedule of the day2 of the event:

  • 1000 – Phi Phạm Hồng (@4nhdaden) of STAR Labs (@starlabs_sg) targeting Oracle VirtualBox in the Virtualization category.
  • 1200 – The Fluoroacetate team of Amat Cama and Richard Zhu targeting Adobe Reader with a Windows local privilege escalation.
  • 1400 – The Synacktiv team of Corentin Bayet (@OnlyTheDuck) and Bruno Pujos (@BrunoPujos) targeting the VMware Workstation in the Virtualization category.
  • 1600 – Special demonstration from Lucas Leong of the Zero Day Initiative against Oracle VirtualBox.

Pierluigi Paganini

(SecurityAffairs – Pwn2Own, cybercrime)

The post Pwn2Own 2020 Day1 -researchers earned $180K for hacking Windows, Ubuntu, and macOS appeared first on Security Affairs.

Six Facts about Address Space Layout Randomization on Windows

Overcoming address space layout randomization (ASLR) is a precondition of virtually all modern memory corruption vulnerabilities. Breaking ASLR is an area of active research and can get incredibly complicated. This blog post presents some basic facts about ASLR, focusing on the Windows implementation. In addition to covering what ASLR accomplishes to improve security posture, we aim to give defenders advice on how to improve the security of their software, and to give researchers more insight into how ASLR works and ideas for investigating its limitations.

Memory corruption vulnerabilities occur when a program mistakenly writes attacker-controlled data outside of an intended memory region or outside intended memory’s scope. This may crash the program, or worse, provide the attacker full control over the system. Memory corruption vulnerabilities have plagued software for decades, despite efforts by large companies like Apple, Google, and Microsoft to eradicate them.

Since these bugs are hard to find and just one can compromise a system, security professionals have designed failsafe mechanisms to thwart software exploitation and limit the damage should a memory corruption bug be exploited. A “silver bullet” would be a mechanism to make exploits so tricky and unreliable that buggy code can be left in place, giving developers the years they need to fix or rewrite code in memory-safe languages. Unfortunately, nothing is perfect, but address space layout randomization (ASLR) is one of the best mitigations available.

ASLR works by breaking assumptions that developers could otherwise make about where programs and libraries would lie in memory at runtime. A common example is the locations of gadgets used in return-oriented programming (ROP), which is often used to defeat the defense of data execution prevention (DEP). ASLR mixes up the address space of the vulnerable process—the main program, its dynamic libraries, the stack and heap, memory-mapped files, and so on—so that exploit payloads must be uniquely tailored to however the address space of the victim process is laid out at the time. Writing a worm that propagates by blindly sending a memory corruption exploit with hard-coded memory addresses to every machine it can find is bound to fail. So long as the target process has ASLR enabled, the exploit’s memory offsets will be different than what ASLR has selected. This crashes the vulnerable program rather than exploiting it.

Fact 1: ASLR was introduced in Windows Vista. Pre-Vista versions of Windows lacked ASLR; worse, they went to great lengths to maintain a consistent address space across all processes and machines.

Windows Vista and Windows Server 2008 were the first releases to feature support for ASLR for compatible executables and libraries. One might assume that prior versions simply didn’t randomize the address space, and instead simply loaded DLLs at whatever location was convenient at the time—perhaps a predictable one, but not necessarily the same between two processes or machines. Unfortunately, these old Windows versions instead went out of their way to achieve what we’ll call “Address Space Layout Consistency”. Table 1 shows the “preferred base address” of some core DLLs of Windows XP Service Pack 3.

DLL

Preferred Base Address

ntdll

0x7c900000

kernel32

0x7c800000

user32

0x7e410000

gdi32

0x77f10000

Table 1: Windows DLLs contain a preferred base address used whenever possible if ASLR is not in place

When creating a process, pre-Vista Windows loads each of the program’s needed DLLs at its preferred base address if possible. If an attacker finds a useful ROP gadget in ntdll at 0x7c90beef, for example, the attacker can assume that it will always be available at that address until a future service pack or security patch requires the DLLs to be reorganized. This means that attacks on pre-Vista Windows can chain together ROP gadgets from common DLLs to disable DEP, the lone memory corruption defense on those releases.

Why did Windows need to support preferred base addresses? The answer lies in performance and in trade-offs made in the design of Windows DLLs versus other designs like ELF shared libraries. Windows DLLs are not position independent. Especially on 32-bit machines, if Windows DLL code needs to reference a global variable, the runtime address of that variable gets hardcoded into the machine code. If the DLL gets loaded at a different address than was expected, relocation is performed to fix up such hardcoded references. If the DLL instead gets loaded as its preferred base address, no relocation is necessary, and the DLL’s code can be directly mapped into memory from the file system.

Directly mapping the DLL file into memory is a small performance benefit since it avoids reading any of the DLL’s pages into physical memory until they are needed. A better reason for preferred base addresses is to ensure that only one copy of a DLL needs to be in memory. Without them, if three programs run that share a common DLL, but each loads that DLL at a different address, there would be three DLL copies in memory, each relocated to a different base. That would counteract a main benefit of using shared libraries in the first place. Aside from its security benefits, ASLR accomplishes the same thing—ensuring that the address spaces of loaded DLLs won’t overlap and loading only a single copy of a DLL into memory—in a more elegant way. Because ASLR does a better job of avoiding overlap between address spaces than statically-assigned preferred load addresses ever could, manually assigning preferred base addresses provides no optimization on an ASLR-capable OS, and is not needed any longer in the development lifecycle.

Takeaway 1.1: Windows XP and Windows Server 2003 and earlier do not support ASLR.

Clearly, these versions have been out of support for years and should be long gone from production use. The more important observation relates to software developers who support both legacy and modern Windows versions. They may not realize that the exact same program can be more secure or less secure depending on what OS version is running. Developers who (still!) have a customer base of mixed ASLR and non-ASLR supporting Windows versions should respond to CVE reports accordingly. The exact same bug might appear non-exploitable on Windows 10 but be trivially exploitable on Windows XP. The same applies to Windows 10 versus Windows 8.1 or 7, as ASLR has become more capable with each version.

Takeaway 1.2: Audit legacy software code bases for misguided ideas about preferred load addresses. 

Legacy software may still be maintained with old tools such as Microsoft Visual C++ 6. These development tools contain outdated documentation about the role and importance of preferred load addresses. Since these old tools cannot mark images as ASLR-compatible, a “lazy” developer who doesn’t bother to change the default DLL address is actually better off since a conflict will force the image to be rebased to an unpredictable location!

Fact 2: Windows loads multiple instances of images at the same location across processes and even across users; only rebooting can guarantee a fresh random base address for all images.

ELF images, as used in the Linux implementation of ASLR, can use position-independent executables and position-independent code in shared libraries to supply a freshly randomized address space for the main program and all its libraries on each launch—sharing the same machine code between multiple processes even where it is loaded at different addresses. Windows ASLR does not work this way. Instead, each DLL or EXE image gets assigned a random load address by the kernel the first time it is used, and as additional instances of the DLL or EXE are loaded, they receive the same load address. If all instances of an image are unloaded and that image is subsequently loaded again, the image may or may not receive the same base address; see Fact 4. Only rebooting can guarantee fresh base addresses for all images systemwide.

Since Windows DLLs do not use position-independent code, the only way their code can be shared between processes is to always be loaded at the same address. To accomplish this, the kernel picks an address (0x78000000 for example on 32-bit system) and begins loading DLLs at randomized addresses just below it. If a process loads a DLL that was used recently, the system may just re-use the previously chosen address and therefore re-use the previous copy of that DLL in memory. The implementation solves the issues of providing each DLL a random address and ensuring DLLs don’t overlap at the same time.

For EXEs, there is no concern about two EXEs overlapping since they would never be loaded into the same process. There would be nothing wrong with loading the first instance of an EXE at 0x400000 and the second instance at 0x500000, even if the image is larger than 0x100000 bytes. Windows just chooses to share code among multiple instances of a given EXE.

Takeaway 2.1: Any Windows program that automatically restarts after crashing is especially susceptible to brute force attacks to overcome ASLR. 

Consider a program that a remote attacker can execute on demand, such as a CGI program, or a connection handler that executes only when needed by a super-server (as in inetd, for example). A Windows service paired with a watchdog that restarts the service when it crashes is another possibility. An attacker can use knowledge of how Windows ASLR works to exhaust the possible base addresses where the EXE could be loaded. If the program crashes and (1) another copy of the program remains in memory, or (2) the program restarts quickly and, as is sometimes possible, receives the same ASLR base address, the attacker can assume that the new instance will still be loaded at the same address, and the attacker will eventually try that same address.

Takeaway 2.2: If an attacker can discover where a DLL is loaded in any process, the attacker knows where it is loaded in all processes. 

Consider a system running two buggy network services—one that leaks pointer values in a debug message but has no buffer overflows, and one that has a buffer overflow but does not leak pointers. If the leaky program reveals the base address of kernel32.dll and the attacker knows some useful ROP gadgets in that DLL, then the same memory offsets can be used to attack the program containing the overflow. Thus, seemingly unrelated vulnerable programs can be chained together to first overcome ASLR and then launch an exploit.

Takeaway 2.3: A low-privileged account can be used to overcome ASLR as the first step of a privilege escalation exploit. 

Suppose a background service exposes a named pipe only accessible to local users and has a buffer overflow. To determine the base address of the main program and DLLs for that process, an attacker can simply launch another copy in a debugger. The offsets determined from the debugger can then be used to develop a payload to exploit the high-privileged process. This occurs because Windows does not attempt to isolate users from each other when it comes to protecting random base addresses of EXEs and DLLs.

Fact 3: Recompiling a 32-bit program to a 64-bit one makes ASLR more effective.

Even though 64-bit releases of Windows have been mainstream for a decade or more, 32-bit user space applications remain common. Some programs have a true need to maintain compatibility with third-party plugins, as in the case of web browsers. Other times, development teams have a belief that a program needs far less than 4 GB of memory and 32-bit code could therefore be more space efficient. Even Visual Studio remained a 32-bit application for some time after it supported building 64-bit applications.

In fact, switching from 32-bit to 64-bit code produces a small but observable security benefit. The reason is that the ability to randomize 32-bit addresses is limited. To understand why, observe how a 32-bit x86 memory address is broken down in Figure 1. More details are explained at Physical Address Extension.


Figure 1: Memory addresses are divided into components, only some of which can be easily randomized at runtime

The operating system cannot simply randomize arbitrary bits of the address. Randomizing the offset within a page portion (bits 0 through 11) would break assumptions the program makes about data alignment. The page directory pointer (bits 30 and 31) cannot change because bit 31 is reserved for the kernel, and bit 30 is used by Physical Address Extension as a bank switching technique to address more than 2GB of RAM. This leaves 14 bits of the 32-bit address off-limits for randomization.

In fact, Windows only attempts to randomize 8 bits of a 32-bit address. Those are bits 16 through 23, affecting only the page directory entry and page table entry portion of the address. As a result, in a brute force situation, an attacker can potentially guess the base address of an EXE in 256 guesses.

When applying ASLR to a 64-bit binary, Windows is able to randomize 17-19 bits of the address (depending on whether it is a DLL or EXE). Figure 2 shows how the number of possible base addresses, and accordingly the number of brute force guesses needed, increases dramatically for 64-bit code. This could allow endpoint protection software or a system administrator to detect an attack before it succeeds.


Figure 2: Recompiling 32-bit code as 64-bit dramatically increases the number of possible base addresses for selection by ASLR

Takeaway 3.1: Software that must process untrusted data should always be compiled as 64-bit, even if it does not need to use a lot of memory, to take maximum advantage of ASLR.

In a brute force attack, ASLR makes attacking a 64-bit program at least 512 times harder than attacking the 32-bit version of the exact same program.

Takeaway 3.2: Even 64-bit ASLR is susceptible to brute force attacks, and defenders must focus on detecting brute force attacks or avoiding situations where they are feasible.

Suppose an attacker can make ten brute force attempts per second against a vulnerable system. In the common case of the target process remaining at the same address because multiple instances are running, the attacker would discover the base address of a 32-bit program in less than one minute, and of a 64-bit program in a few hours. A 64-bit brute force attack would produce much more noise, but the administrator or security software would need to notice and act on it. In addition to using 64-bit software to make ASLR more effective, systems should avoid re-spawning a crashing process (to avoid giving the attacker a “second bite at the apple” to discover the base address) or force a reboot and therefore guaranteed fresh address space after a process crashes more than a handful of times.

Takeaway 3.3: Researchers developing a proof of concept attack against a program available in both 32-bit and 64-bit versions should focus on the 32-bit one first.

As long as 32-bit software remains relevant, a proof-of-concept attack against the 32-bit variant of a program is likely easier and quicker to develop. The resulting attack could be more feasible and convincing, leading the vendor to patch the program sooner.

Fact 4: Windows 10 reuses randomized base addresses more aggressively than Windows 7, and this could make it weaker in some situations.

Observe that even if a Windows system must ensure that multiple instances of one DLL or EXE all get loaded at the same base address, the system need not keep track of the base address once the last instance of the DLL or EXE is unloaded. If the DLL or EXE is loaded again, it can get a fresh base address.

This is the behavior we observed in working with Windows 7. Windows 10 can work differently. Even after the last instance of a DLL or EXE unloads, it may maintain the same base address at least for a short period of time—more so for EXEs than DLLs. This can be observed when repeatedly launching a command-line utility under a multi-process debugger. However, if the utility is copied to a new filename and then launched, it receives a fresh base address. Likewise, if a sufficient duration has passed, the utility will load at a different base address. Rebooting, of course, generates fresh base addresses for all DLLs and EXEs.

Takeaway 4.1: Make no assumptions about Windows ASLR guarantees beyond per-boot randomization.

In particular, do not rely on the behavior of Windows 7 in randomizing a fresh address space whenever the first instance of a given EXE or DLL loads. Do not assume that Windows inherently protects against brute force attacks against ASLR in any way, especially for 32-bit processes where brute force attacks can take 256 or fewer guesses.

Fact 5: Windows 10 is more aggressive at applying ASLR, and even to EXEs and DLLs not marked as ASLR-compatible, and this could make ASLR stronger.

Windows Vista and 7 were the first two releases to support ASLR, and therefore made some trade-offs in favor of compatibility. Specifically, these older implementations would not apply ASLR to an image not marked as ASLR-compatible and would not allow ASLR to push addresses above the 4 GB boundary. If an image did not opt in to ASLR, these Windows versions would continue to use the preferred base address.

It is possible to further harden Windows 7 using Microsoft’s Enhanced Mitigation Experience Toolkit (commonly known as EMET) to more aggressively apply ASLR even to images not marked as ASLR-compatible. Windows 8 introduced more features to apply ASLR to non-ASLR-compatible images, to better randomize heap allocations, and to increase the number of bits of entropy for 64-bit images.

Takeaway 5.1: Ensure software projects are using the correct linker flags to opt in to the most aggressive implementation of ASLR, and that they are not using any linker flags that weaken ASLR.

See Table 2. Linker flags can affect how ASLR is applied to an image. Note that for Visual Studio 2012 and later, the ✔️flags are already enabled by default and the best ASLR implementation will be used so long as no 🚫flags are used. Developers using Visual Studio 2010 or earlier, presumably for compatibility reasons, need to check which flags the linker supports and which it enables by default.

Secure?

Linker Flag

Effect

✔️

/DYNAMICBASE

Marks the image as ASLR-compatible

✔️

/LARGEADDRESSAWARE /HIGHENTROPYVA

Marks the 64-bit image as free of pointer truncation bugs and therefore allows ASLR to randomize addresses beyond 4 GB

🚫

/DYNAMICBASE:NO

“Politely requests” that ASLR not be applied by not marking the image as ASLR-compatible. Depending on the Windows version and hardening settings, Windows might apply ASLR anyway.

🚫

/HIGHENTROPYVA:NO

Opts out 64-bit images from ASLR randomizing addresses beyond 4 GB on Windows 8 and later (to avoid compatibility issues).

🚫

/FIXED

Removes information from the image that Windows needs in order to apply ASLR, blocking ASLR from ever being applied.

Table 2: Linker flags can affect how ASLR is applied to an image

Takeaway 5.2: Enable mandatory ASLR and bottom-up randomization.

Windows 8 and 10 contain optional features to forcibly enable ASLR on images not marked as ASLR compatible, and to randomize virtual memory allocations so that rebased images obtain a random base address. This is useful in the case where an EXE is ASLR compatible, but one of the DLLs it uses is not. Defenders should enable these features to apply ASLR more broadly, and importantly, to help discover any remaining non-ASLR-compatible software so it can be upgraded or replaced.

Fact 6: ASLR relocates entire executable images as a unit.

ASLR relocates executable images by picking a random offset and applying it to all addresses within an image that would otherwise be relative to its base address. That is to say:

  • If two functions in an EXE are at addresses 0x401000 and 0x401100, they will remain 0x100 bytes apart even after the image is relocated. Clearly this is important due to the prevalence of relative call and jmp instructions in x86 code. Similarly, the function at 0x401000 will remain 0x1000 bytes from the base address of the image, wherever it may be.
  • Likewise, if two static or global variables are adjacent in the image, they will remain adjacent after ASLR is applied.
  • Conversely, stack and heap variables and memory-mapped files are not part of the image and can be randomized at will without regard to what base address was picked.

Takeaway 6.1: A leak of just one pointer within an executable image can expose the randomized addresses of the entire image.

One of the biggest limitations and annoyances of ASLR is that seemingly innocuous features such as a debug log message or stack trace that leak a pointer in the image become security bugs.  If the attacker has a copy of the same program or DLL and can trigger it to produce the same leak, they can calculate the difference between the ASLR and pre-ASLR pointer to determine the ASLR offset. Then, the attacker can apply that offset to every pointer in their attack payload in order to overcome ASLR. Defenders should train software developers about pointer disclosure vulnerabilities so that they realize the gravity of this issue, and also regularly assess software for these vulnerabilities as part of the software development lifecycle.

Takeaway 6.2: Some types of memory corruption vulnerabilities simply lie outside the bounds of what ASLR can protect.

Not all memory corruption vulnerabilities need to directly achieve remote code execution. Consider a program that contains a buffer variable to receive untrusted data from the network, and a flag variable that lies immediately after it in memory. The flag variable contains bits specifying whether a user is logged in and whether the user is an administrator. If the program writes data beyond the end of the receive buffer, the “flags” variable gets overwritten and an attacker could set both the logged-in and is-admin flags. Because the attacker does not need to know or write any memory addresses, ASLR does not thwart the attack. Only if another hardening technique (such as compiler hardening flags) reordered variables, or better, moved the location of every variable in the program independently, would such attacks be blocked.

Conclusion

Address space layout randomization is a core defense against memory corruption exploits. This post covers some history of ASLR as implemented on Windows, and also explores some capabilities and limitations of the Windows implementation. In reviewing this post, defenders gain insight on how to build a program to best take advantage of ASLR and other features available in Windows to more aggressively apply it. Attackers can leverage ASLR limitations, such as address space randomization applying only per boot and randomization relocating the entire image as one unit, to overcome ASLR using brute force and pointer leak attacks.

I’m still on Windows 7 – what should I do?

Support for Windows 7 has ended, leaving Marcy wondering how they can protect themselves

I do a lot of work on a Windows 7 desktop PC that is about five years old. I’m a widow and can’t afford to run out and get a new PC at this time, or pay for Windows 10. If I do stay with Windows 7, what should I worry about, and how can I protect myself? I have been running Kaspersky Total Security for several years, which has worked well so far. Marcy

Microsoft Windows 7 – launched in 2009 – came to the end of its supported life on Tuesday. Despite Microsoft’s repeated warnings to Windows 7 users, there may still be a couple of hundred million users, many of them in businesses. What should people do next?

Continue reading...

SharPersist: Windows Persistence Toolkit in C#

Background

PowerShell has been used by the offensive community for several years now but recent advances in the defensive security industry are causing offensive toolkits to migrate from PowerShell to reflective C# to evade modern security products. Some of these advancements include Script Block Logging, Antimalware Scripting Interface (AMSI), and the development of signatures for malicious PowerShell activity by third-party security vendors. Several public C# toolkits such as Seatbelt, SharpUp and SharpView have been released to assist with tasks in various phases of the attack lifecycle. One phase of the attack lifecycle that has been missing a C# toolkit is persistence. This post will talk about a new Windows Persistence Toolkit created by FireEye Mandiant’s Red Team called SharPersist.

Windows Persistence

During a Red Team engagement, a lot of time and effort is spent gaining initial access to an organization, so it is vital that the access is maintained in a reliable manner. Therefore, persistence is a key component in the attack lifecycle, shown in Figure 1.


Figure 1: FireEye Attack Lifecycle Diagram

Once an attacker establishes persistence on a system, the attacker will have continual access to the system after any power loss, reboots, or network interference. This allows an attacker to lay dormant on a network for extended periods of time, whether it be weeks, months, or even years. There are two key components of establishing persistence: the persistence implant and the persistence trigger, shown in Figure 2. The persistence implant is the malicious payload, such as an executable (EXE), HTML Application (HTA), dynamic link library (DLL), or some other form of code execution. The persistence trigger is what will cause the payload to execute, such as a scheduled task or Windows service. There are several known persistence triggers that can be used on Windows, such as Windows services, scheduled tasks, registry, and startup folder, and there continues to be more discovered. For a more thorough list, see the MITRE ATT&CK persistence page.


Figure 2: Persistence equation

SharPersist Overview

SharPersist was created in order to assist with establishing persistence on Windows operating systems using a multitude of different techniques. It is a command line tool written in C# which can be reflectively loaded with Cobalt Strike’s “execute-assembly” functionality or any other framework that supports the reflective loading of .NET assemblies. SharPersist was designed to be modular to allow new persistence techniques to be added in the future. There are also several items related to tradecraft that have been built-in to the tool and its supported persistence techniques, such as file time stomping and running applications minimized or hidden.

SharPersist and all associated usage documentation can be found at the SharPersist FireEye GitHub page.

SharPersist Persistence Techniques

There are several persistence techniques that are supported in SharPersist at the time of this blog post. A full list of these techniques and their required privileges is shown in Figure 3.

Technique

Description

Technique Switch Name (-t)

Admin Privileges Required?

Touches Registry?

Adds/Modifies Files on Disk?

KeePass

Backdoor KeePass configuration file

keepass

No

No

Yes

New Scheduled Task

Creates new scheduled task

schtask

No

No

Yes

New Windows Service

Creates new Windows service

service

Yes

Yes

No

Registry

Registry key/value creation/modification

reg

No

Yes

No

Scheduled Task Backdoor

Backdoors existing scheduled task with additional action

schtaskbackdoor

Yes

No

Yes

Startup Folder

Creates LNK file in user startup folder

startupfolder

No

No

Yes

Tortoise SVN

Creates Tortoise SVN hook script

tortoisesvn

No

Yes

No

Figure 3: Table of supported persistence techniques

SharPersist Examples

On the SharPersist GitHub, there is full documentation on usage and examples for each persistence technique. A few of the techniques will be highlighted below.

Registry Persistence

The first technique that will be highlighted is the registry persistence. A full listing of the supported registry keys in SharPersist is shown in Figure 4.

Registry Key Code (-k)

Registry Key

Registry Value

Admin Privileges Required?

Supports Env Optional Add-On (-o env)?

hklmrun

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

Yes

Yes

hklmrunonce

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

Yes

Yes

hklmrunonceex

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx

User supplied

Yes

Yes

userinit

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Userinit

Yes

No

hkcurun

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

No

Yes

hkcurunonce

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

No

Yes

logonscript

HKCU\Environment

UserInitMprLogonScript

No

No

stickynotes

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

RESTART_STICKY_NOTES

No

No

Figure 4: Supported registry keys table

In the following example, we will be performing a validation of our arguments and then will add registry persistence. Performing a validation before adding the persistence is a best practice, as it will make sure that you have the correct arguments, and other safety checks before actually adding the respective persistence technique. The example shown in Figure 5 creates a registry value named “Test” with the value “cmd.exe /c calc.exe” in the “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” registry key.


Figure 5: Adding registry persistence

Once the persistence needs to be removed, it can be removed using the “-m remove” argument, as shown in Figure 6. We are removing the “Test” registry value that was created previously, and then we are listing all registry values in “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” to validate that it was removed.


Figure 6: Removing registry persistence

Startup Folder Persistence

The second persistence technique that will be highlighted is the startup folder persistence technique. In this example, we are creating an LNK file called “Test.lnk” that will be placed in the current user’s startup folder and will execute “cmd.exe /c calc.exe”, shown in Figure 7.


Figure 7: Performing dry-run and adding startup folder persistence

The startup folder persistence can then be removed, again using the “-m remove” argument, as shown in Figure 8. This will remove the LNK file from the current user’s startup folder.


Figure 8: Removing startup folder persistence

Scheduled Task Backdoor Persistence

The last technique highlighted here is the scheduled task backdoor persistence. Scheduled tasks can be configured to execute multiple actions at a time, and this technique will backdoor an existing scheduled task by adding an additional action. The first thing we need to do is look for a scheduled task to backdoor. In this case, we will be looking for scheduled tasks that run at logon, as shown in Figure 9.


Figure 9: Listing scheduled tasks that run at logon

Once we have a scheduled task that we want to backdoor, we can perform a dry run to ensure the command will successfully work and then actually execute the command as shown in Figure 10.


Figure 10: Performing dry run and adding scheduled task backdoor persistence

As you can see in Figure 11, the scheduled task is now backdoored with our malicious action.


Figure 11: Listing backdoored scheduled task

A backdoored scheduled task action used for persistence can be removed as shown in Figure 12.


Figure 12: Removing backdoored scheduled task action

Conclusion

Using reflective C# to assist in various phases of the attack lifecycle is a necessity in the offensive community and persistence is no exception. Windows provides multiple techniques for persistence and there will continue to be more discovered and used by security professionals and adversaries alike.

This tool is intended to aid security professionals in the persistence phase of the attack lifecycle. By releasing SharPersist, we at FireEye Mandiant hope to bring awareness to the various persistence techniques that are available in Windows and the ability to use these persistence techniques with C# rather than PowerShell.

Commando VM 2.0: Customization, Containers, and Kali, Oh My!

The Complete Mandiant Offensive Virtual Machine (“Commando VM”) swept the penetration testing community by storm when it debuted in early 2019 at Black Hat Asia Arsenal. Our 1.0 release made headway featuring more than 140 tools. Well now we are back again for another spectacular release, this time at Black Hat USA Arsenal 2019! In this 2.0 release we’ve listened to the community and implemented some new must have features: Kali Linux, Docker containers, and package customization.

About Commando VM

Penetration testers commonly use their own variants of Windows machines when assessing Active Directory environments. We specifically designed Commando VM to be the go-to platform for performing internal penetration tests. The benefits of using Commando VM include native support for Windows and Active Directory, using your VM as a staging area for command and control (C2) frameworks, more easily (and interactively) browsing network shares, and using tools such as PowerView and BloodHound without any worry about placing output files on client assets.

Commando VM uses Boxstarter, Chocolatey, and MyGet packages to install software and delivers many tools and utilities to support penetration testing. With over 170 tools and growing, Commando VM aims to be the de facto Windows machine for every penetration tester and red teamer.

Recent Updates

Since its initial release at Black Hat Asia Arsenal in March 2019, Commando VM has received three additional updates, including new tools and/or bug fixes. We closed 61 issues on GitHub and added 26 new tools. Version 2.0 brings three major new features, more tools, bug fixes, and much more!

Kali Linux

In 2016 Microsoft released the Windows Subsystem for Linux (WSL). Since then, pentesters have been trying to leverage this capability to squeeze more productivity out of their Window systems. The fewer Virtual Machines you need to run, the better. With WSL you can install Linux distributions from the Windows Store and run common Linux commands in a terminal such as starting up an SSH, MySQL or Apache server, automating mundane tasks with common scripting languages, and utilizing many other Linux applications within the same Windows system.

In January 2018, Offensive Security announced support for Kali Linux in WSL. With our 2.0 release, Commando VM officially supports Kali Linux on WSL. To get the most out of Kali, we've also included VcXsrv, an X Server that allows us to display the entire Linux GUI on the Windows Desktop (Figure 1). Displaying the Linux GUI and passing windows to Windows had been previously documented by Offensive Security and other professionals, and we have combined these to include the GUI as well as shortcuts to take advantage of popular programs such as Terminator (Figure 2) and DirBuster (Figure 3).


Figure 1: Kali XFCE on WSL with VcXsrv


Figure 2: Terminator on Commando VM – Kali WSL with VcXsrv


Figure 3: DirBuster on Commando VM – Kali WSL with VcXsrv

Docker

Docker is becoming increasingly popular within the penetration testing community. Multiple blog posts exist detailing interesting functionality using Docker for pentesting. Based on its popularity Docker has been on our roadmap since the 1.0 release in March 2019, and we now support it with our release of Commando VM 2.0. We pull tools such as Amass and SpiderFoot and provide scripts to launch the containers for each tool. Figure 4 shows an example of SpiderFoot running within Docker.


Figure 4: Impacket container running on Docker

For command line docker containers, such as Amass, we created a PowerShell script to automatically run Amass commands through docker. This script is also added to the PATH, so users can call amass from anywhere. This script is shown in Figure 5. We encourage users to come up with their own scripts to do more creative things with Docker.


Figure 5: Amass.ps1 script

This script is also executed when the shortcut is opened.


Figure 6: Amass Docker container executed via PowerShell script

Customization

Not everyone needs all of the tools all of the time. Some tools can extend the installation process by hours, take up many gigabytes of hard drive space, or come with unsuitable licenses and user agreements. On the other hand, maybe you would like to install additional reversing tools available within our popular FLARE VM; or you would prefer one of the many alternative text editors or browsers available from the chocolatey community feed. Either way, we would like to provide the option to selectively install only the packages you desire. Through customization you and your organization can also share or distribute the profile to make sure your entire team has the same VM environment. To provide for these scenarios, the last big change for Commando 2.0 is the support for installation customization. We recommend using our default profile, and removing or adding tools to it as you see fit. Please read the following section to see how.

How to Create a Custom Install

Before we start, please note that after customizing your own edition of Commando VM, the cup all command will only upgrade packages pre-installed within your customized distribution. New packages released by our team in the future will not be installed or upgraded automatically with cup all. When needed, these new packages can always be installed manually using the cinst or choco install command, or by adding them to your profile before a new install.

Simple Instructions

  1. Download the zip from https://github.com/fireeye/commando-vm into your Downloads folder.
  2. Decompress the zip and edit the ${Env:UserProfile}\Downloads\commando-vm-master\commando-vm-master\profile.json file by removing tools or adding tools in the “packages” section. Tools are available from our package list or from the chocolatey repository.
  3. Open an administrative PowerShell window and enable script execution.
    • Set-ExecutionPolicy Unrestricted -f
  4. Change to the unzipped project directory.
    • cd ${Env:UserProfile}\Downloads\commando-vm-master\commando-vm-master\
  5. Execute the install with the -profile_file argument.
    • .\install.ps1 -profile_file .\profile.json

Detailed Instructions

To start customizing your own distribution, you need the following three items* from our public GitHub repository:

  1. Our install.ps1 script
  2. Our sample profile.json
  3. An installation template. We recommend using commandovm.win10.install.fireeye.

*Note: If you download the project ZIP from GitHub it will contain all three items.

The install script will now support an optional -profile_file argument, which specifies a JSON profile. Without the -profile_file argument, running .\install.ps1 will install the default Commando VM distribution. To customize your edition of Commando VM, you need to create a profile in JSON format, and then pass that to the -profile_file argument. Let us explore the sample profile.json profile (Figure 7).


Figure 7: profile.json profile

This JSON profile starts with the env dictionary which specifies many environment variables used by the installer. These environment variables can, and should, be left to their default values. Here is a list of the supported environment variables:

  • VM_COMMON_DIR specifies where the shared libraries should be installed on the VM. After a successful install, you will find a FireEyeVM.Common directory within this location. This contains a PowerShell module that is shared by our packages.
  • TOOL_LIST_DIR and TOOL_LIST_SHORTCUT specify which directory contains the list of all installed packages within the Start Menu and the name of the desktop shortcut, respectively.
  • RAW_TOOLS_DIR environment variable specifies the location where some tools will be installed. Chocolatey defaults to installing tools in %ProgramData%\Chocolatey\lib. This environment variable by default points to %SystemDrive%\Tools, allowing you to more easily access some tools on the command line.
  • And, finally, TEMPLATE_DIR specifies a template package directory relative to where install.ps1 is on disk. We strongly recommend using the commandovm.win10.installer.fireeye package available on our GitHub repository as the template. If your VM is running Windows 7, please switch to the appropriate commandovm.win7.installer.fireeye package. If you are feeling “hacky” and adventurous, feel free to customize the installer further by modifying the chocolateyinstall.ps1 and chocolateyuninstall.ps1 scripts within the tools directory of the template. Note that a proper template will be a folder containing at least 5 things: (1) a properly formatted nuspec file, (2) a “tools” folder that contains (3) a chocolateyinstall.ps1 file, (4) a chocolateyuninstall.ps1 file, and (5) a profile.json file. If you use our template, the only thing you need to change is the packages.json file. The easiest way to do this is just download and extract the commando-vm zip file from GitHub.

With the packages variables set, you can now specify which packages to install on your own distribution. Some packages accept additional installation arguments. You can see an example of this by looking at the openvpn.fireeye entry. For a complete list of packages available from our feed, please see our package list.

Once you finish modifying your profile, you are ready for installation. Run powershell.exe with elevated privileges and execute the following commands to install your own edition of Commando VM, assuming you saved your version of the profile named: myprofile.json (Figure 8).


Figure 8: Example myprofile.json

The myprofile.json file can then be shared and distributed throughout your entire organization to ensure everyone has the same VM environment when installing Commando VM.

Conclusion

Commando VM was originally designed to be the de facto Windows machine for every penetration tester and red teamer. Now, with the addition of Kali Linux support, Docker and installation customization, we hope it will be the one machine for all penetration testers and red teamers. For a complete list of tools, and for the installation script, please see the Commando VM GitHub repository. We look forward to addressing user feedback, adding more tools and features, and creating many more enhancements for this Windows attack platform.

Commando VM: The First of Its Kind Windows Offensive Distribution


For penetration testers looking for a stable and supported Linux testing platform, the industry agrees that Kali is the go-to platform. However, if you’d prefer to use Windows as an operating system, you may have noticed that a worthy platform didn’t exist. As security researchers, every one of us has probably spent hours customizing a Windows working environment at least once and we all use the same tools, utilities, and techniques during customer engagements. Therefore, maintaining a custom environment while keeping all our tool sets up-to-date can be a monotonous chore for all. Recognizing that, we have created a Windows distribution focused on supporting penetration testers and red teamers.

Born from our popular FLARE VM that focuses on reverse engineering and malware analysis, the Complete Mandiant Offensive VM (“Commando VM”) comes with automated scripts to help each of you build your own penetration testing environment and ease the process of VM provisioning and deployment. This blog post aims to discuss the features of Commando VM, installation instructions, and an example use case of the platform. Head over to the Github to find Commando VM.

About Commando VM

Penetration testers commonly use their own variants of Windows machines when assessing Active Directory environments. Commando VM was designed specifically to be the go-to platform for performing these internal penetration tests. The benefits of using a Windows machine include native support for Windows and Active Directory, using your VM as a staging area for C2 frameworks, browsing shares more easily (and interactively), and using tools such as PowerView and BloodHound without having to worry about placing output files on client assets.

Commando VM uses Boxstarter, Chocolatey, and MyGet packages to install all of the software, and delivers many tools and utilities to support penetration testing. This list includes more than 140 tools, including:

With such versatility, Commando VM aims to be the de facto Windows machine for every penetration tester and red teamer. For the blue teamers reading this, don’t worry, we’ve got full blue team support as well! The versatile tool sets included in Commando VM provide blue teams with the tools necessary to audit their networks and improve their detection capabilities. With a library of offensive tools, it makes it easy for blue teams to keep up with offensive tooling and attack trends.


Figure 1: Full blue team support

Installation

Like FLARE VM, we recommend you use Commando VM in a virtual machine. This eases deployment and provides the ability to revert to a clean state prior to each engagement. We assume you have experience setting up and configuring your own virtualized environment. Start by creating a new virtual machine (VM) with these minimum specifications:

  • 60 GB of disk space
  • 2 GB memory

Next, perform a fresh installation of Windows. Commando VM is designed to be installed on Windows 7 Service Pack 1, or Windows 10, with Windows 10 allowing more features to be installed.

Once the Windows installation has completed, we recommend you install your specific VM guest tools (e.g., VMware Tools) to allow additional features such as copy/paste and screen resizing. From this point, all installation steps should be performed within your VM.

  1. Make sure Windows is completely updated with the latest patches using the Windows Update utility. Note: you may have to check for updates again after a restart.
  2. We recommend taking a snapshot of your VM at this point to have a clean instance of Windows before the install.
  3. Navigate to the following URL and download the compressed Commando VM repository onto your VM:
  4. Follow these steps to complete the installation of Commando VM:
    1. Decompress the Commando VM repository to a directory of your choosing.
    2. Start a new session of PowerShell with elevated privileges. Commando VM attempts to install additional software and modify system settings; therefore, escalated privileges are required for installation.
    3. Within PowerShell, change directory to the location where you have decompressed the Commando VM repository.
    4. Change PowerShell’s execution policy to unrestricted by executing the following command and answering “Y” when prompted by PowerShell:
      • Set-ExecutionPolicy unrestricted
    5. Execute the install.ps1 installation script. You will be prompted to enter the current user’s password. Commando VM needs the current user’s password to automatically login after a reboot. Optionally, you can specify the current user’s password by passing the “-password <current_user_password>” at the command line.


Figure 2: Install script running

The rest of the installation process is fully automated. Depending upon your Internet speed the entire installation may take between 2 to 3 hours to finish. The VM will reboot multiple times due to the numerous software installation requirements. Once the installation completes, the PowerShell prompt remains open waiting for you to hit any key before exiting. After completing the installation, you will be presented with the following desktop environment:


Figure 3: Desktop environment after install

At this point it is recommended to reboot the machine to ensure the final configuration changes take effect. After rebooting you will have successfully installed Commando VM! We recommend you power off the VM and then take another snapshot to save a clean VM state to use in future engagements.

Proof of Concept

Commando VM is built with the primary focus of supporting internal engagements. To showcase Commando VMs capabilities, we constructed an example Active Directory deployment. This test environment may be contrived; however, it represents misconfigurations commonly observed by Mandiant’s Red Team in real environments.

We get started with Commando VM by running network scans with Nmap.


Figure 4: Nmap scan using Commando VM

Looking for low hanging fruit, we find a host machine running an interesting web server on TCP port 8080, a port commonly used for administrative purposes. Using Firefox, we can connect to the server via HTTP over TCP port 8080.


Figure 5: Jenkins server running on host

Let’s fire up Burp Suite’s Intruder and try brute-forcing the login. We navigate to our Wordlists directory in the Desktop folder and select an arbitrary password file from within SecLists.


Figure 6: SecLists password file

After configuring Burp’s Intruder and analyzing the responses, we see that the password “admin” grants us access to the Jenkins console. Classic.


Figure 7: Successful brute-force of the Jenkins server

It’s well known that Jenkins servers come installed with a Script Console and run as NT AUTHORITY\SYSTEM on Windows systems by default. We can take advantage of this and gain privileged command execution.


Figure 8: Jenkins Script Console

Now that we have command execution, we have many options for the next step. For now, we will investigate the box and look for sensitive files. Through browsing user directories, we find a password file and a private SSH key.


Figure 9: File containing password

Let’s try and validate these credentials against the Domain Controller using CredNinja.


Figure 10: Valid credentials for a domain user

Excellent, now that we know the credentials are valid, we can run CredNinja again to see what hosts the user might have local administrative permissions on.


Figure 11: Running CredNinja to identify local administrative permissions

It looks like we only have administrative permissions over the previous Jenkins host, 192.168.38.104. Not to worry though, now that we have valid domain credentials, we can begin reconnaissance activities against the domain. By executing runas /netonly /user:windomain.local\niso.sepersky cmd.exe and entering the password, we will have an authenticated command prompt up and running.


Figure 12: cmd.exe running as WINDOMAIN\niso.sepersky

Figure 12 shows that we can successfully list the contents of the SYSVOL file share on the domain controller, confirming our domain access. Now we start up PowerShell and start share hunting with PowerView.


Figure 13: PowerView's Invoke-ShareFinder output

We are also curious about what groups and permissions are available to the user account compromised. Let’s use the Get-DomainUser module of the post-exploitation framework PowerView to retrieve user details from Active Directory. Note that Commando VM uses the “dev” branch of PowerView by default.


Figure 14: Get-DomainUser win

We also want to check for further access using the SSH key we found earlier. Looking at our port scans we identify one host with TCP port 22 open. Let’s use MobaXterm and see if we can SSH into that server.


Figure 15: SSH with MobaXterm

We access the SSH server and also find an easy path to rooting the server. However, we weren’t able to escalate domain privileges with this access. Let’s get back to share hunting, starting with that hidden Software share we saw earlier. Using File Explorer, it’s easy to browse shares within the domain.


Figure 16: Browsing shares in windomain.local

Using the output from PowerView’s Invoke-ShareFinder command, we begin digging through shares and hunting for sensitive information. After going through many files, we finally find a config.ini file with hardcoded credentials.


Figure 17: Identifying cleartext credentials in configuration file

Using CredNinja, we validate these credentials against the domain controller and discover that we have local administrative privileges!


Figure 18: Validating WINDOMAIN\svcaccount credentials

Let’s check group memberships for this user.


Figure 19: Viewing group membership of WINDOMAIN\svcaccount

Lucky us, we’re a member of the “Domain Admins” group!

Final Thoughts

All of the tools used in the demo are installed on the VM by default, as well as many more. For a complete list of tools, and for the install script, please see the Commando VM Github repo. We are looking forward to addressing user feedback, adding more tools and features, and creating many enhancements. We believe this distribution will become the standard tool for penetration testers and look forward to continued improvement and development of the Windows attack platform.