Windows 11 SSH Client - No Matching Key

 When trying to ssh to a device from Windows 11 I received the following error:

Unable to negotiate with x.x.x.x port 22: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1

Solution

You can specify the key exchange method via command line by using the following command:

ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 x.x.x.x

Alternatively you can create a file named "config" with no file extension under %USERPROFILE%\.ssh and include the line below in the file. 

KexAlgorithms=+diffie-hellman-group14-sha1

Using Nessus Parser (Melcara) Script - Ubuntu 22.04

 Over the years I've used this Nessus Parser script from Cody Dumont @ http://www.melcara.com/. Thank you Cody! The script was last updated on September 25th, 2017, but it still works great. It's a Perl script and does a great job of merging .nessus files and exporting in a very usable Excel format. I find the stock Nessus reports subpar and overly verbose. I understand Tenable's motive for intentionally leaving this functionality out of Nessus Pro, but find it frustrating nonetheless. The Nessus Parser script works great for consolidating vulnerability results, reporting, and ongoing vulnerability management. Particularly for smaller organizations that have a hard time justifying the high cost of Tenable's Security Center or similar. 

There are some dependencies that need to be installed to use the script. In the past I've installed the dependencies via the commands below:

cpan install XML::TreePP Data::Dumper Math::Round Excel::Writer::XLSX Data::Table Excel::Writer::XLSX::Chart Getopt::Std

I've had trouble installing these at times and have alternatively used the commands below. These recently worked for me on Ubuntu 22.04. 

apt-get install libxml-simple-perl

apt-get install libxml-treepp-perl

apt-get install libxml-mathround-perl

apt-get install libmath-round-perl

apt-get install libxml-mathround-perl

apt-get install libexcel-writer-xlsx-perl

apt-get install perl-tables-data

apt-get install libdata-table-perl

To run the script, copy your .nessus files to a directory (/home/user/Nessus), change permissions on the script to allow execute, and run it:

chmod +x parse_nessus_xml.v24.pl 

perl parse_nessus_xml.v24.pl -d /home/user/Nessus/

This will create a new .xslx file in the provided directory. I like to re-format the Excel document using the procedure below:

1. Copy the Summary info (text only) to a new sheet

2. Delete all tabs except Vulnerability to IP Summary and the new summary sheet

3. Filter out "Informational" items from Vulnerability to IP Summary

4. Copy Vulnerability to IP Summary (text only) into a new sheet

5. Delete Column 1

6. Center and Middle Align all columns

7. Word wrap Plugin Name and IP Address columns

8. Sort by severity and color code

9. If desired, filter out previously accepted vulns

10. Move similar vulnerabilities next to each other

11. Add blank rows beneath each vulnerability

12. Format Mitigation row @ 50px

Applocker Resources

NSA Applocker Whitepaper

https://github.com/nsacyber/AppLocker-Guidance

GitHub - microsoft/AaronLocker: Robust and practical application control for Windows

Disabling UAC Remote Restrictions to Limit Credential Exposure

Did you know UAC settings affect remote login privileges? Over the years I've bumped into this and never took the time to fully understand what was happening. I'm writing this post as a quick reference for myself and also to propose a counterintuitive way to limit credential exposure.  Will Schroeder (@harmj0y) wrote an excellent post in 2017 where he laid out some misconceptions and answered a lot of questions about pass-the-hash and how UAC remote restrictions affects remote logins. Based on Will's post and a few Microsoft articles, I've put together a quick chart showing how UAC affects remote logins when using different accounts.

Note: This chart assumes UAC is enabled via HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

Using the Built-in Administrator (RID 500) for Remote Administration

By default the built-in administrator (RID 500) account connects with full administrative privileges, meaning that UAC Remote Restrictions are not applied. However, if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken is enabled (set to 1), the RID 500 account is enrolled in UAC protection. The Group Policy setting for this is "User Account Control: Admin Approval Mode for the built-in Administrator account" and it is disabled by default. Microsoft has a good article that describes UAC Group Policy settings and the corresponding registry keys here.

Using a Domain Account That is a Member of the Administrators Group for Remote Administration

UAC remote restrictions aren't applied to domain users. If the account is in the Administrators group on the target, full administrator rights will be granted and UAC is disabled for that session.

Using a Local Admin (Non RID 500 SAM account) for Remote Administration

By default, a non RID 500 local admin will not connect as a full administrator, has no elevation potential, and cannot perform administrative tasks. In order to administer the workstation the user must interactively login. However, if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy is enabled, all local users connecting remotely are granted full administrative rights.

So why would you possibly set this registry entry?

Will says in his post, "So why would you possibly set this registry entry?" in regard to LocalAccountTokenFilterPolicy, which effectively disables UAC remote restrictions. Well, I think there are a couple scenarios where we can use this setting to actually limit credential exposure. Disabling UAC remote restrictions with LocalAccountTokenFilterPolicy is a bad idea if you have local admin accounts with the same passwords across the enterprise. When an attacker lands a foothold and finds the combination of shared local admin creds and disabled UAC remote restrictions, they'll be able to use the credentials to move laterally and it'll be game over quickly. 

However, by now we should know better than to use the same credentials for local admin accounts. Microsoft LAPs is one solution. If you're setting unique local admin passwords, once exposed they're useless on other systems. Another control that I'm a big fan of, is to isolate user systems from each other via Windows Firewall rules or other means. Ideally, a combination of such controls would be implemented in case one were to fail. If you're implementing controls like these, disabling UAC remote restrictions doesn't have much impact. Local admin accounts will be able to remotely perform administrative tasks. If local admin credentials are compromised, they're only good on the compromised system. An attacker can't use the credentials to login to another system.

Let's flip this concept around in an attempt to use this to our advantage. What are some situations in which using local admin credentials could be beneficial? How about patching, running backups, deploying software, or running vulnerability scans? Many times these tasks are being run via privileged domain accounts. Depending on how each application logs in, these credentials may be left behind on every machine that's accessed. When an attacker lands a foothold, we have the same credential exposure problem we had with local accounts. If we instead ran these tasks with unique local admin credentials and disabled UAC remote restrictions in order to do this, we're limiting our exposure. This may make credential management more difficult, but I find it manageable. Instead of using an all-powerful account and spraying those credentials everywhere, we're use local admin accounts to limit our exposure. This approach may not scale to large environments, but for small/medium networks it has worked for me. Another way to limit exposure would be to use an account that is a member of the Protected Users group. This would force Kerberos and only leave a ticket with a short lifespan on the system; however, this unfortunately seems to break the functionality of some admin tools. 

I see this especially useful not so much for workstations, but for servers. Particularly for scanning and deploying patches and backup job credentials. For workstations, I prefer to isolate user systems. That way deployment credentials are only good from admin subnets and servers used for patch management, vulnerability scans, etc.  You could use this strategy for workstations as well, and some applications like PDQ Deploy integrate with Microsoft LAPs to make credential management easier. 

What are your thoughts on this? As always if I missed anything or you have something to contribute, please comment below. 

File Extensions to Block at Email Gateway

I've combined my file extension block list for email gateways with @HackerHurricane's from his Slideshare here, @cyb3rops list from his ransomware prevention document here, and Microsoft's list from here. Let me know if you have more to add.

.386, .ace, .acm, .acv, .ade, .adp, .adt, .ani, .app, .arc, .arj, .asd, .asp, .asx, .avb, .ax, .bas, .bat, .bin, .boo, .btm, .cab, .cbt, .cdr, .cer, .chm, .cla, .cmd, .cnt, .cnv, .com, .cpl, .crt, .csc, .csh, .css, .der, .dll, .drv, .dvb, .email, .exe, .fon, .fxp, .gadget, .gms, .grp, .gvb, .hlp, .hpj, .ht, .HTA, .htlp, .htt, .inf, .ini, .ins, .iso, .isp, .its, .jar, .jnlp, .job, .js, .jse, .ksh, .lib, .lnk, .mad, .maf, .mag, .mam, .maq, .mar, .mas, .mat, .mau, .mav, .maw, .mcf, .mch, .mda, .mdb, .mde, .mdt, .mdw, .mdz, .mht, .mhtm, .mhtml, .mpd, .mpt, .msc, .msh, .msh1, .msh1xml, .msh2, .msh2xml, .mshxml, .MSI, .mso, .msp, .mst, .nws, .obd, .obj, .obt, .obz, .ocx, .ops, .osd, .ovl, .ovr, .pcd, .pci, .perl, .pgm, .pif, .pl, .plg, .pot, .prf, .prg, .ps1, .ps1xml, .ps2, .ps2xml, .psc1, .psc2, .pst, .pub, .pwz, .qpw, .reg, .sbf, .scf, .scr, .sct, .sfx, .sh, .shb, .shs, .shtml, .shw, .smm, .svg, .sys, .td0, .tlb, .tmp, .torrent, .tsk, .tsp, .tt6, .url, .vb, .vbe, .vbp, .vbs, .vbscript, .vbx, .vom, .vsd, .vsmacro, .vsmacros, .vss, .vst, .vsw, .vwp, .vxd, .vxe, .wbk, .wbt, .wiz, .wk, .wml, .wms, .wpc, .wpd, .ws, .wsc, .wsf, .wsh, .xbap, .xll, .xnk

Deploy Credential Guard - Windows 10

Credential Guard is an awesome feature in Windows 10 that is designed to prevent credential theft even on a system that is completely compromised. I think it's safe to say we can thank Benjamin Delpy (@gentilkiwi) and others like Chris Campbell and Skip Duckwall for the advent of Credential Guard. Ben's tool, Mimikatz, as well as Chris and Skip's Pass-the-Hash research definitely brought this issue into the spotlight and put additional pressure on Microsoft to put some R&D into the problem. 

Credential Guard uses what Microsoft calls "Virtualization based security" to isolate credentials so that malware or attackers with admin privileges can't view or extract them. For more information on why this is so important see my previous post which links to my Derbycon talk. TLDR; When (not if) one of your systems gets compromised, attackers look for credentials and move around laterally until they get what they want. Without Credential Guard it is trivial to view credentials that Windows stores in memory. Depending on the version of Windows these credentials may be in plaintext, hashed, or in the form of a Kerberos ticket.

For example, here is the output of Mimikatz on a Windows 10 system running as a local user and not joined to a domain:

Here you can see the local user's hash that is stored in memory. If this was Windows 7, by default you would see the actual password in plaintext. Now lets look at the output when Credential Guard is enabled:

But wait, it looks like the NTLM hash is still accessible in memory? I confirmed with Benjamin Delpy that this is indeed the case when running Windows 10 LTSB 2015 with a local account. He said this has been fixed in the Anniversary Update so this shouldn't be the case when running LTSB 2016 or the latest Windows 10 CSB. I joined the machine to a domain and on the results were what I originally expected with no credentials accessible:

Configuring Credential Guard

So how do we turn this on? The first thing you need to consider is the prerequisites, which vary depending on the version of Windows 10. At a minimum, you'll need:

• 64-bit CPU with virtualization extensions such as Intel VT-x or AMD-V
• TPM 1.2 or 2.
• UEFI firmware with Secure Boot enabled
• Windows 10 Enterprise, Education, 2016 Server or Enterprise IoT

You can enable Credential Guard via GPO, registry, or with a Microsoft provided Powershell script; however keep in mind the prerequisites must already be in place for Credential Guard to be successfully enabled. If the system didn't have Secure Boot enabled when Windows was installed, you'll have to enable Secure Boot and re-install Windows before Credential Guard will work. On my list of things to do is to find a way to poll systems remotely (probably with Powershell) and output a report on Credential Guard status. Also notice Credential Guard can't be run on Windows 10 Pro. In my mind Credential Guard and Device Guard are the primary motivating reasons to buy Enterprise.

For initial testing, my preferred method of enabling Credential Guard is with the DG_Readiness Powershell script from Microsoft which you can currently find here. This tool allows you to verify a system has the required prerequisites, enable or disable Credential Guard or Device Guard or both, and check to see if they are enabled/running. Run it with the -Capable flag to check the prerequisites:

Don't worry if you see HSTI Validation failed. I'm not exactly sure what this means but it doesn't seem to affect Credential Guard. If you see any other errors in red you'll need to fix those before you can enable Credential Guard. If you don't see any other errors you can run the Readiness Tool with the -Enable flag which will enable both Credential Guard and Device Guard. I ran into an issue when enabling CG this way where some applications wouldn't start because of a "digital signature" error. Running the Readness Tool with the -Disable -DG flags fixed the issue by disabling Device Guard. I assume this had to do with Device Guard being enabled but no configuration for it. Because of this issue, I'd recommend enabling Credential Guard with the -Enable -CG flags as shown:

When the system reboots Credential Guard should be running. You can verify this with the Readiness Tool and the -Ready flag or by running msinfo32.exe. This is what they should look like:

Credential Guard Configured But Services Not Running

When running Windows 10 LTSB 2016 or CSB I've ran into an issue where in msinfo32.exe it appears Credential Guard is configured, but the services are not running. I'm not sure what causes this, but the workaround below worked for me.

• Ensure all prerequisites are in place on the system
• Configure Credential Guard with the Readiness Tool
• After a reboot msinfo32.exe shows Credential Guard configured, but services not running
• Disable Secure Boot in the BIOS
• After a reboot msinfo32.exe shows Credential Guard configured and oddly services running even though Secure Boot is disabled
• Re-Enable Secure Boot
• After a reboot msinfo32.exe shows Credential Guard configured and services remain running

Update - 7-11-17

Ran into this again on an HP Prodesk 600 G1 SFF and the workaround above didn't work. When I looked at tpm.msc it showed "TPM Not Ready". I initialized the TPM from tpm.msc, rebooted, and had to confirm a BIOS message to initialize the chip. I then disabled Credential Guard and re-enabled it with the readiness script and then Credential Guard Services showed "Running" in msinfo32.exe. 

Other Notes

In my experience you can't image a machine when Credential Guard is enabled.

Additional Resources

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

https://blogs.technet.microsoft.com/poshchap/2016/09/23/security-focus-check-credential-guard-status-with-powershell/

Deploying Privileged Access Workstations - Derbycon Talk and Slides

Here is the recording of my Derbycon talk on deploying privileged access workstations and other ways to limit lateral movement and credential theft. Here are the slides from that talk - http://www.slideshare.net/BlueTeamer/deploying-privileged-access-workstations-paws-66374801.

I'll also be giving an updated version of this talk at Dakotacon 2017. Hope to see you there!