Positive Security

A necessary component to any IR: Containment

kplaxmaster — Fri, 02 Mar 2018 13:25:21 GMT

This blog is updated at https://ciberesponce.com

Incident Response and Containment

Anyone who does Incident Response (IR), or any Digital Forensics Incident Response (DFIR) process knows that collecting Indicators of Compromise (IOC) is only half the story. Eventually, you'll need to recover the environment, which inherently means you best have confidence in the IOCs and have a plan to evict the adversary. Before we go into detail on just how to do that, it is paramount to talk about containment. Anytime a recovery team comes in and takes intel from the IR team, a plan must be executed while being sensitive to the control-plane an adversary should have after a step has been executed. For example, if Exchange environment and the general Users population gets compromised, one should not just cleanup the Exchange environment, but they should also protect it from being re-contaminated by potentially other compromised areas of the environment. So, we do this very important task via Identity-containment methodologies. What you will find, though, is that this doesn't just give us containment but also gives us higher assurances that we discovered the IOCs against a particular actor(s). This additional detection mechanism can give any response team the greenlight to either get the IR team back involved as adversarial activities are still being discovered after an eviction attempt or identity potentially dangerously configured applications (or perhaps an admin who exposed the wrong cred to the wrong system).

How to build containment

An often-underutilized policy that allows us to dictate who can logon to what system is User Rights Assignments. In addition, User Rights Assignments are only useful if we can target machines, which is where Organizational Units (OUs) come into play. Lastly, Security Groups come in handy to group various users (and potentially other Security Groups) together, so we can assign policy to them. Every “container” we want to make, needs an OU. For example, we need an OU for Tier-0. We would then assign policy, via User Rights Assignments, so only Tier-0 credentials can logon to those machines; it would be denied from authenticating against the other OUs. That said, for every container we need:

An OU (to target computers)
A Security Group (to bundle users/Groups together)
A User Rights Assignment policy properly linked and configured

Since Denys take precedence over Allows in ACLs, not only do we want to allow Tier-0 accounts to log into Tier-0 machines (identified via an OU), we want to also deny them from logging in to the other OUs. This is the premise of containment, at the Identity level. There are other methods of containment, including Network, however, network containment is often not enough in the world of credential harvesting. A last note about Containment. Once we put these policies in place, we can actually see adversaries try to break out of our newly built containers using technologies like Azure Security Center. Once we collect all these events, we can look at Event ID 4625 and look for particular “Failure Reason”.

Note again that these actions shouldn’t be done until the IR team has finished its investigation. This doesn’t mean the “hunt” is over; many times, during the recovery, additional IOCs can be discovered as containment methodologies and hardening guidance are put into place.

Any Failure Reason with the value "%%2308", or in English, "The user has not been granted the requested logon type (aka logon right) at this machine", should be a red flare in the sky. It should be followed up on, in coordination with the IT staff. Lastly, containment methodologies can and should be applied to service accounts as well as local accounts.

Service accounts

Since service accounts are also harvestable, and typically have privileges across multiple computers, they are prime targets for adversaries to laterally move. Besides using Azure ATP to detect anomalous behavior of such accounts, User Rights Assignments can also be used to ensure Service accounts act like Service accounts; that is, they can’t be used to RDP or any other interactive logon. User Rights Assignments can also help drastically increase visibility into an environment during the IR. If you are unable to still find how the adversary is in, but there are indications they are still in, use these to pinpoint exactly where they are and continuously harden the environment. Eventually you’ll pinpoint the location of the adversary while at the same time executing critical Tactical Recovery steps. Any breaks from this policy either means foobar happened (or a bad application using a service account interactively) or an adversary is actively trying to break out of the credential containers URA’s help create. One should use Azure Security Center and Log Analytics to peer into these events.

Local Accounts

You should ensure Local Accounts that are Members of the Local Admin Group (S-1-5-114) cannot be used to laterally move. Local accounts should only be used in Break Glass scenarios. Refer to Aaron Margosis’ blog on this topic: https://blogs.technet.microsoft.com/secguide/2014/09/02/blocking-remote-use-of-local-accounts/

Note that this doesn’t prevent local admins from logging on remotely, it just means the accounts can’t be used to ‘hop’ after the initial logon. In addition, this only pertains to Windows 7+ as the new SID wasn’t backported to all Operating Systems.

When this approach is used, Local Accounts can’t be used to laterally move—forcing the adversary to use other means, such as domain accounts. This increases our Return of Investment (ROI) on technologies such as Azure ATP, which log domain user activities. Now you have a building block to build a more confident recovery effort. Of course, prevention (which provides additional detection/awareness and visibility as well) isn't a be-it-all solution. A perfect complement to containment is continuous monitoring capabilities looking for malicious activity based on behavior, specific Azure ATP and Windows Defender ATP. These solutions should be used starting from the IR and throughout the Recovery process (and ultimately passed that to prevent this from happening again!). Happy hunting! Andrew

Setting up Kali Linux in Docker on Windows 10

kplaxmaster — Fri, 01 Sep 2017 15:54:08 GMT

This blog is updated at https://ciberesponce.com A few times now, I find myself wondering why I need a full blown VM. I like need to quickly get my tools up and running on any hardware I find myself on. Most of the time that is a fresh installed Windows 10 on my Surface Book—I like messing things up to a point of no return… what can I say? As I illustrated the beauty of "Bash on Ubuntu on Windows" in the Azure Security Center's SQL-Injection Playbook, I realized there really must be a better way to bring Kali Linux over to Windows as well. As many know, Kali is a customized Linux distribution, based on Debian. I could, in theory, install Ubuntu and install the Kali repositories and go from there—in addition, I like to stay away from multiple repositories from multiple parties on the same packages. Possible, but a configuration nightmare to maintain and troubleshoot. Kali's official documentation seems to agree with me. The next best thing is Containers. In the Windows world, this requires Windows 10 Anniversary Edition+. You'll be able to enable Containers, Install Docker, and pull a Kali Linux image all in 10 minutes or less (download speeds may vary ).

Installing the Containers Feature and Installing Docker

First, we must enable the "Containers" feature. Run (ctrl+r) "optionalfeatures".

And make sure this "Containers" option is checked off.

Once that completes, follow these instructions to install docker: https://docs.docker.com/docker-for-windows/install/. Grab the Stable channel Windows MSI and install it. Once you get it to install, you need to log out and log back in. NOTE: Although Docker stated it just needed a log-out/log-in, in order for the Docker service to run on my machine it required a reboot.

After logging back in, in your notifications, you should get a "Docker is starting…".

Pull Official Kali Linux Docker Image

We will be following the guidance here: https://www.kali.org/news/official-kali-linux-docker-images/ Open up your favorite command line interface (CLI). Then type "docker pull kalilinux/kali-linux-docker". This will pull the image from the Docker Store.

Now, let us enter an interactive bash session with that image by typing "docker run -t -I kalilinux/kali-linux-docker /bin/bash"

We are now in our fresh install of Kali. Since this install is meant to be the minimal, you need to grab the packages you actually care about. This helps keep the image small but does require a good Internet connection to get up and running. Before installing any package, let's upgrade our Kali Linux and remove all packages we no longer need via "apt update && apt full-upgrade && apt auto-remove && apt-autoclean"

Installing the Metasploit Framework

Lastly, let us install the go-to package for most pentesters… Metasploit. A simple command of "apt install metasploit-framework ruby" will do the trick.

Just start up the PostgresSQL database that Metasploit uses, initialize the database, and to msfconsole we go!

Happy Hunting, Andrew (@ciberesponce)

WMI Queries: ReturnValue vs uValue (and some Remote Registry)

kplaxmaster — Thu, 24 Aug 2017 12:44:42 GMT

This blog is updated at https://ciberesponce.com Interestingly, when querying a registry setting in Windows via WMI, through PowerShell, it isn't as straight forward as previously thought. When developing the Audit Policy settings tool, which uses WMI through PowerShell explicitly to avoid dependencies on Windows Remote Management (WinRM) or even the Remote Registry service, we hit a bug in our logic. What we discovered can be summarized here: uValue will give you the raw value. Does the key exist or not, and if it does, whats the value? Seems straight forward... but how do you know what the default OS setting is--which also could mean the key doesn't even exist!? That is where ReturnValue comes in--even if the key doesn't exist, it will return the default OS setting. What makes this confusing is, if you explicitly create the key, even if it mimics the default OS value, ReturnValue changes! So, what did we need to do to get around this?

Reproducing the bug

Default Behavior

By default, Server 2008+ has Advanced Audit Policies Enforced. That means, even without the "SYSTEM\CurrentControlSet\Control\Lsa\scenoapplylegacyauditpolicy" registry key, the system will give it a value of 1. When you query the DC without this value (meaning the default value of the OS), you get:

For the Property "ReturnValue", we get a 1. For the "uValue" we get a 0.

Explicitly setting value to 1 (Enforced is enabled, same effect as no value/OS-default)

However, when we explicitly set the policy with a 1 (meaning still enforced), we get these results:

ReturnValue now has a value of '0'. However, uValue has a value of '1'. Well this is interesting…

Explicitly setting value to 0 (disabling it; not a security best practice)

Now, for testing purposes, lets explicitly disable the Enforcement of Advanced Audit settings by setting the "scenoapplylegacyauditpolicy" value to '0'. Here is the result we get this time:

This time neither value is 1.

Our new logic…

Based on the above, we need to update our logic; "ReturnValue" property is no longer as useful to us anymore. I could have checked either property to see if they are "1" and if so, all is good. However, by just taking the uValue, I can:

If uValue == 0: Enforcement is disabled
Else (1 or nul): Enforcement is enabled

What about Remote Registry

Remote Registry, through testing, will always give you the "uValue". Special thanks to Kurt Falde (whose GitHub Audit checker I used as a reference for part of this), Brian Mahaffey and Jon Stevenson. Happy hunting (or in this case, measuring compliance so you can effectively hunt)! Andrew (@ciberesponce)

ATA Auditing (AuditPol, Advanced Audit Settings Enforcement, Lightweight Gateway Service discovery)

kplaxmaster — Fri, 18 Aug 2017 13:38:43 GMT

This blog is updated at https://ciberesponce.com

NOTE: This blog and code was updated to include a new targeting feature so only 1 domain/child-domain can be targeted for assessment. This will still discover all DCs in the Forest, however, only the DCs in the targeted domain will be assessed.

Advanced Threat Analytics (ATA) v1.8 added new capabilities to monitor suspicious and anomalous activity within an Active Directory domain. This increased the number of Event ID's ATA requires. Customizing the Domain Controller's Audit Settings could stop the Domain Controller from auditing activities required by ATA. This customization is common in many organizations and can have a negative impact on ATA. Additionally, many Cyber shops are not aware of their Domain Controller's current audit policy settings nor the level of effort (LOE) changes in ATA v1.8 with Gateways vs. Lightweight Gateways (LWGWs). Starting in ATA 1.8 the LWGWs' event ID's are automatically read and required data is extracted. Meanwhile for Gateways, event IDs still must manually be forwarded or sent to the ATA Gateway. In previous versions of ATA, the only event required was event ID 4776. In ATA v1.8, ATA requires the following event IDs 4732, 4733, 4728, 4729, 4756, 4757 in addition to 4776. This script will help make sense of the above variables to ensure you are in good status.

About the script

First off, the script is located here: https://aka.ms/AtaAuditing In this script, we:

Discover all Domain Controllers (DC)
Via WMI, enumerate if Audit Policy settings are enforced (a Microsoft best practice; on by default)
Via WMI, enumerate the Audit Policy settings per DC
Via WMI, discover if the DC has the ATA Lightweight Gateway (LWGW) installed or not
Compares the outputs above and provides a high-level status

We chose WMI since it is always on for Domain Controllers and is a much more reliable method than Windows Remote Management (WinRM). In addition, just like the ATA Sizing Tool, it is very light weight. Further, this allows you, our customer, to test that ATA v1.8 can detect WMI Execution against the Domain Controller 😊. Eventually, we will push this script into the ATA Sizing Tool script, which uses the same WMI protocol. The script will be officially "supported" by Microsoft when it is merged into the ATA sizing Tool. In the meantime, we didn't want to wait – so we decided to publish early!

Running the script

The script requires Domain Admin (or equivalent) privileges to execute. This can be done from the Domain Controller itself or from an admin workstation where such credentials can be exposed (i.e. "Admin Workstation"). If running from a Domain Controller, the script ensures that we only query 10 other DCs at a time, thus throttling the script. To run the script, simply download the script and its supporting files and execute from the path ".\Measure-AtaDeployment.ps1". Again, by default, this will throttle the script to 10 DCs at one time, and will assess the environment against ATA v1.8 requirements. If you have multiple Domains in a single Forest, ensure the script is executed with Enterprise Admin (or equivalent) privileges. However, if you are running this from a non-DC, or don't want to be limited by the built-in throttling, you can execute the script using the "RunJobsThrottle" parameter:

And, for whatever reason you are still on ATA v1.7, use the "AtaVersion" parameter to set this to "1.7":

To target just a particular domain/child-domain, use the "Fqdn" parameter. In this example, we will only target the "child.contoso.com" domain. Note that the script will still discover all domain controllers in the Forest, but it will only do the assessment against the DCs in the provided domain. In addition, this parameter is not required and thus, by default, the assessment will be at the Forest and all respective Domain Controllers.

Results

The results are provided back in both the PowerShell console and exported as CSV, in a "Results" folder in the same location as where the script is when executed. Because we believe in "run once, use many", we decided to preserve the raw Audit Policy results for each DC. If you have no other use-case for these, simply ignore them and only look at the "Assessment-{date}" file. However, you might find other great information in those files…

The Assessment Results are in a CSV file and will nicely show you which DCs are LWGW, which have the right policy settings, and if something failed, it will show you where it failed:

Fixing Issues

If advanced audit setting policies are enforced, remediation of any issues is trivial. However, if issues are identified, use the following resources to help remediate:

For more information on Force audit policy subcategories: https://technet.microsoft.com/en-us/library/dd772710(v=ws.10).aspx
For enabling a audit policy subcategory: https://docs.microsoft.com/en-us/windows/device-security/auditing/advanced-security-audit-policy-settings

What about that WMI Code Execution detection in ATA v1.8?

In the above example, we can see each DC's FQDN, their overall Status and the specific assessment results. You can see that even if all the assessment results come back good, we make a friendly reminder for all non-LWGWs to ensure events are manually being forwarded to the ATA Center. For more on that, please refer here; note that we support Windows Event Forwarding (WEF) and Windows Event Collector (WEC); instructions here. And, as promised, ATA v1.8 detects WMI Execution against the DC. Since this script is doing just that, executing very specific commands on the DCs via the WMI protocol, ATA detects this. In my lab environment, thanks to ATA, you know exactly from where the Post Deployment script was ran (and by who).

To further test ATA's detection capabilities, we recommend you head to the ATA SA Playbook.

Getting Help

Until this fully merges into the ATA Sizing tool, any issues or questions can be sent to aharri@microsoft.com and askcesec@microsoft.com. If having issues, please do attach the transcript, located in the "Transcript" folder.

Happy hunting! Andrew (@cibereponce) Reviewers: Gershon (@gman4626) Marie (@mariegroover)

ATA + OMS

kplaxmaster — Thu, 08 Jun 2017 20:23:44 GMT

This blog is updated at https://ciberesponce.com Installing Operational Management Suite (OMS) on top of Advanced Threat Analytics (ATA) is dead simple. It is even more simple if your ATA Center is installed in Azure as deploying the OMS agent on Azure VMs is one click. OMS continues to gain momentum as it provides a single-pane-of-glass. It's integration into things like Azure Automation allow for very wide and interesting use-cases. Fusion with the Microsoft Security Graph (provided by source from Microsoft and its third parties where we spend over $10M USD/year) makes it all that much powerful. This blog will build on the previous blogpost on this topic, located here. In this referenced blog, The Scripting Guys discuss in detail on why Syslog is better then both SMTP and the Windows Event Log route. Note that we aren't saying turn off Windows Event Log/Windows Event Forwarding into ATA Center, this is specific to getting events out of the ATA Center. Let's get started.

Configure ATA

Once you get ATA installed (whether on-prem or in Azure, as long as it's up and running and has Gateways), we need to configure it's syslog. From the ATA Console, on the top right, select the options button, then "Configuration" button.

In the Syslog navigation pane, use the following settings:

The "Syslog server endpoint" should be 127.0.0.7 with the port 5114. Note that 127.0.0.7 is not a typo, this is another dedicated IP for localhost. Once we insert these values, press the blue button at the bottom, "Send test syslog message". That is literally all that is needed to be configured with ATA. The OMS installation is just as easy…

Create OMS Workspace (if needed)

From the Azure Portal, if you already have an existing OMS/Log Analytics Portal, great, use that one. If not, select the Log Analytics Button:

Then, let's go ahead and select "Add" and fill out the respective data.

Great, we are almost done.

Connect ATA Center to OMS Workspace

If you decided to install the ATA Center in Azure, you are a few clicks away from connecting the VM to your workspace. Under the "Workspace data sources" section, select "Virtual Machines" and find your ATA Center VM in the list. Then press the "Connect" button. That's it!

If you decided to install ATA Center on-prem, no worries, your install is almost just as easy. Follow this guide here: https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-windows-agents#download-the-agent-setup-file-from-oms

Test the connection

Once you see the connection successful, let's get bits on the wire and see them show up. The quickest way is to run the very first attack we introduce in the ATA Playbook. Attempting to do a Zone Transfer from a machine against the Domain/DNS-server will trigger an alert. From any computer, perform the following nslookup command to attempt to dump the contents of the DNS server:

As you see the "Query refused", go back to OMS and wait for it to show up. You won't wait too long. Back in the OMS Portal, in the "Security And Audit" view, we should see the new "SecurityDetection" alert. Clicking on the alert, our Log Search view opens up where we can start doing all sorts of great queries against this and all other OMS data sources!

We now OMS integration on our ATA—tested and approved. Happy hunting! Andrew

Setting up Damn Vulnerable Web App (DVWA) on Ubuntu in Azure

kplaxmaster — Thu, 01 Jun 2017 22:04:06 GMT

This blog is updated at https://ciberesponce.com Getting familiar with attacks is step one of knowing what you're up against. One way to do that is getting a vulnerable application to hit against and sharpen your skills. Nothing beats Damn Vulnerable Web App (DVWA). Here are the steps to get Damn Vulnerable Web App up and running in the Azure environment, all done via SSH (no RDP required).

Deploy Ubuntu 16.04 LTS

As you should always use the latest Ubuntu version, it's also important to stay 'stable'. To that end, we recommend sticking with the Long Term Support (LTS) versions of Ubuntu to get the best support.

SSH into machine once deployed

I typically recommend Bash for Windows, installing SSH. Alternative is a PowerShell SSH here.

Add repository to get php5.6

Run the following command to add the repository to get PHP 5.6 to work on Ubuntu 16.04. DVWA requires this version of PHP as it was written for it. The DVWA app itself would need to be rewritten for later versions of PHP; thus in the meantime, do this.

sudo add-apt-repository ppa:ondrej/php

Update and install

After installing the new repo, let's update what packages apt-get will discover and install the necessary packages for PHP5.6

sudo apt-get update
sudo apt-get install php5.6 php5.6-mbstring php5.6-mcrypt php5.6-mysql php5.6-xml php5.6-gd

Install mysql

Time to install MySQL

sudo apt-get install mysql-server

Remember password for root of mysql (we use it later)

Install Git (to pull down DVWA)

We will use Git to pull down DVWA via GitHub, so first, of course, we need git!

sudo apt-get install git

Clone DVWA against GitHub

Now let's pull down the bits…

cd /var/www/html
sudo git clone https://github.com/ethicalhack3r/DVWA

Modify DVWA settings for MySQL permissions

Time to configure DVWA to know about our MySQL settings

cd DVWA/
sudo vi config/config.inc.php.dist

Modify 'db_password' parameter for MySQL password (from step 5):

Modify permissions to give Apache privileges to traverse directory

In order for Apache to have permissions to present or even execute any of the PHP code (the DVWA itself!), we need to give it permissions. Since this is "damn vulnerable", let's make it even more so with a chmod 777

sudo chmod -R 777 /var/www/html/DVWA

Move the PHP Config file

Now let's move our configured DVWA file to a file that makes it of value… (done by the DVWA folks on purpose…):

cp config/config.inc.php.dist config/config.inc.php

Set apache's Server Name

We need Apache to stop complaining about not knowing its Fully Qualified Domain Name (FQDN). Let's give it just what it wants…

sudo vi /etc/apache2/apache2.conf

Configure PHP to enable Apache URL Includes

Configure to enable PHP to support "allow_url_encodes". This is necessary for the DVWA to work.

sudo vi /etc/php/5.6/apache2/php.ini
Find "allow_url_include" parameter and set it to "On" (line 835)

Restart Apache

Now that we made changes, specifically around PHP and the permissions in the DVWA folder, we should restart the Apache service.

sudo /etc/init.d/apache2 restart

Ensure Azure NSG can forward HTTP traffic to this machine

All should be good. Now we just need to configure Azure to make this HTTP endpoint routable via the Network Security Group of the VM. Go to the NSG mapped to this VM and make the following changes:

Add to inbound security rules for HTTP traffic

Your inbound rule policies should now look like this:

Traverse in browser to public IP of Ubuntu machine

Almost done, now we just need to head to the location we just configured everything. Go to the site's URL, adding /DVWA to it. It will forward you to the setup.php url below (knowing the application needs to be setup still).

Press "Create / Reset Database". Watch all the successes happen :)

Login and one last configuration…

Hard part is done. Now we login… User: admin Pass: password In DVWA Security tab, make DVWA go to "Low" settings (i.e. Vulnerable)

Happy hacking! Andrew

SmartCard and Pass-the-Hash

kplaxmaster — Wed, 17 May 2017 16:05:08 GMT

On a pretty consistent basis, SmartCard and Multi-factor Authentication (MFA) technologies are brought up when discussing Pass-the-Hash/Pass-the-Ticket with customers. Many customers believe they do not need to worry about such attacks as they have non-repudiation. However, what Smartcard was set to solve was before Pass-the-Hash/Ticket (or Overpass-the-Hash) was a real thing! At that time, preventing users from providing their cleartext password to a fake website (i.e. waterhole attack) was the goal--how could we prevent that from happening? Here, hardware-backed authentication was born. There was no password to leak, as the user himself/herself didn't know it either! They simply had a pin, backed with hardware public key encryption. But one small issue... At that time, the threat was really loss of a plaintext password. On the backend, a random NTLM hash was given to the user. The NTLM hash stays the same--until the user changes their password. But if the user doesn't know their password, how would they change it? There lies part of the problem... but there was a larger previously unknown threat evolving...

"What Smartcard was set to solve was before Pass-the-Hash/Ticket (or Overpass-the-Hash) was a real thing"

Then, Pass-the-Hash became a thing which Mimikatz and Windows Credential Editor (WCE) made popular. Here, the adversary doesn't even care anymore about the entropy of the NTLM hash (or that the user doesn't even technically have a known cleartext password), they simply harvest the credentials in memory (NTLM hash, Kerberos TGT) and use it to inject it in other processes to masquerade as that user. But without a smartcard, how is that possible? Well, SmartCard Required for Interactive Logon (SCRIL) has two very important words in it: "Interactive Logon". Interactive Logons are only 2 types of logons that can occur: What does this mean? I can steal the NTLM hash and move laterally with that credential via the other logon types! Don't try to prevent SCRIL-enabled users from only doing these two logons either—this will break things like allowing them to manage devices and be productive employees by automating some of their own tasks. Better yet, lets focus on the problem. What a better way to do that then a quick video? :)

So now what do we do with this, knowing the actual risk? Well first, first step is knowledge. Next step, lets see how we can roll those NTLM hashes. We will provide two solutions below. And of course, we fully recommend our customers and anyone focused on targeted attacks to leverage Advanced Threat Analytics!

PowerShell Script

Here, a script is provided that discovers your Smartcard Required Interactive Logon (SCRIL) users, and turns the SCRIL-bit off and on. It is this time when the NTLM-hash is randomized. https://blogs.technet.microsoft.com/poshchap/2015/05/08/security-focus-resetting-smart-card-is-required-for-interactive-logon/

Domain Functional Level 2016

Domain Functional Level (DFL) 2016 includes a new feature to help get past some of the limitations of the PowerShell script. This is fully supported by Microsoft and we recommend anyone who is using Smartcard Required for Interactive Logon (SCRIL) to turn this bit on! For more on this: https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/whats-new-in-credential-protection Welp, that is the quick and dirty on this topic. Please do check out Advanced Threat Analytics to discover this and other attacks in your environment by focusing on Identity. Leave questions in the comments!

Ubuntu RDP in Azure

kplaxmaster — Fri, 17 Mar 2017 18:01:40 GMT

Many times, I get a question on how do you RDP into a Linux machine created in Azure. So, instead of having the same conversation over and over, I'll blog about it and point folks here . And going one step further, I figured now was a good time to also test out OpenSSH-Win32. In addition, this will show you how to do this via the new Azure Portal (vs the Classic Azure portal); managing endpoints is slightly different between the two UIs. First, if you are on a Windows box, grab OpenSSH-Win32 here. Note that this is still a preview feature as Microsoft continues to port the OpenSSH client to the Windows world, through PoweShell. If you missed this pretty wild announcement, check the announcement here. Traverse to where you extracted the files, and connect to the IP address of your Ubuntu server in Azure. As you will see, this is real OpenSSH:

Figure 1: OpenSSH-Win32

Cool! Now we got SSH on Windows and we are connected to our system.

Ubuntu Configurations

Now, let's get two things installed:

xubuntu-desktop (xrdp does not support gnome desktop for Ubuntu in versions 12.04LTS or higher).
xrdp (rdp server)

Easy…

Figure 2: sudo apt-get install xubuntu-desktop

And…

Figure 3: sudo apt-get install xrdp

All that is left is starting the xrdp server (in theory this should start with Ubuntu by default but I like the "trust no one" philosophy… worst case it will yell and tell me the service is already starting!):

And now we must ensure the xfce4 (xubuntu) is enabled.

Figure 4: xfce4-session > ~/.xsession; Note, if you are enabling this for another user, add the user then do this for their home profile instead

Next, edit the /etc/xrdp/startwm.sh script, via: "sudo vi /etc/xrdp/startwm.sh" The file should look something like this when you are done (insert the "xfce4-session" line before the ". /etc/x11/xsession" line).

Then we just need to restart xrdp We now have what we need installed and configured on Ubuntu.

Azure Configurations

Now we need to add the Endpoint to Azure on this machine. Without modifying this, we wouldn't have the right NSG rules on the Azure side to allow the RDP traffic to the VM. Go to the associated Network Security Group (NSG) for this VM, which should be created by default when configuring the VM. From the NSG blade for this resource, we can then add the endpoint. We could also do this via PowerShell if we so choose. Click the add button to the inbound rules, and go ahead and configure this:

We now have two endpoints on this system, again which is managed via the NSG for the VM:

Make the RDP Connection

Notice that when we configured RDP it had to be port 3389. That deserves a separate blog at a different time, including what can be done via Azure Security Center and detecting threats on this port. We can now use our handy dandy RDP Connection Manager and make the RDP session.

Now, time to make this a vulnerable web application and show the power of Azure Security Center (ASC)… which shall be another blog post for another day. Andrew

cpassword – MS14-025

kplaxmaster — Thu, 23 Feb 2017 18:40:15 GMT

Microsoft announced MS14-025 on 13 May, 2014. However, it continues to be an issue for many IT organizations, even when patched. I repeat, by simply installing the KB you have not fully remediated the vulnerability (elevate of privileges!) unless you ran the provided PowerShell code to ensure you don't have any existing cpassword Group Policies. For starters… just how bad is MS14-025? Well, I'm glad you asked. It allows an adversary to jump from regular user and directly become local admin if they can discover a vulnerable policy in SYSVOL. How can this be done? Well, any domain entity has the ability to read from SYSVOL, which is how Group Policies are disseminated across an Enterprise! This means, that even a spearphish email campaign can lead to local admin rights to the adversary, even if you spent tons of time ensuring your users don't run as local admin. I repeat, all that work is for nothing unless you do this and run this script—the KB/patch simply ensures you can no longer create bad policies, it doesn't disable/delete the existing ones! Not only this, but many times this policy manages a local admin account across computers, meaning it can be used to laterally move as well, drastically increasing the likelihood an adversary will find the keys to the kingdom, a domain admin or other highly privileged domain account (or any of these accounts with Tier-0 equivalency). Our guidance remains here. Hackers are taking advantage of this for years and unfortunately are very successful via this still. Tools like PowerSploit automatically discover these and reverse the symmetrically encrypted password (that Microsoft was forced to publish, which is/has been on MSDN giving attackers such access), giving the attacker the plaintext password. However, for Incident Responders and those who want to go further than just checking for these policies but to truly understand what is at stake if/when they are discovered, I've developed one that extends our previous guidance. It can be found here: http://aka.ms/cpasswordscript. As the screenshot shows, policies can be complex, including possibly even having the account disabled! Knowing this information could really help drive the urgency if/when such policies are discovered… you should certainly always delete these and transition to our free Local Account Password Solution (LAPS; http://aka.ms/LAPS, which leverages Group Policy Objects Client Side Extensions (CSE)!), but obviously we know there are many other actions an IT team has, many of which are priority. And of course, IR teams should run this whenever they head to a customer… without running this, you potentially are missing a massive gap. My script above keeps provides relevant data to make relevant decisions, so you:

Can quickly tell if the policy has the account disabled
Can quickly see impacted user
Can quickly assess the exact Path of the where the policy is
Can quickly identify the exact GP Global Unique ID (GUID) (this can easily be used to remove such policies if ran with the right privileges)

The script doesn't give you the plaintext password, purely to prevent potential liability if your team is external to the customer whom you are providing a service to. However, just know, its easily decrypted which is why this vulnerability exists in the first place. Hopefully this helps someone and stop another Fortune 500 or major government entity from being completely compromised because of a single Group Policy they didn't know existed… And do let us know if you have discovered such policies in your environment or if you have any questions on the above. Andrew

ATA Playbook Released

kplaxmaster — Wed, 15 Feb 2017 04:11:42 GMT

The Advanced Threat Analytics Playbook is released. It includes a breakdown of how to test (and therefor learn!) ATA and the real-world research tools that are available on the public Internet. The goal here was simple:

Debunk some myths around pass-the-hash (i.e. SmartCards)
Show how these research tools work (and just how easy it is and what they can do)
Learn what to do about it so your environment isn't a victim of this!

The playbook walks through lab setup to picking up these research tools to showing you how to think like an attacker. All for free Check it out here: http://aka.ms/ataplaybook Evaluate ATA: http://aka.ms/ataeval Leave comments here if you have questions or suggestions! Cheers, Andrew