Tag: security

Retrieving Password from Application Pool

I came across an undocumented app the other day. For a number of reasons, we needed to restore the password but it wasn’t documented anywhere. Luckily, the service account was setup in an app pool. In IIS 7.0 or 7.5, APPCMD can be used to recover the password. In 6.0, adsutil.vbs can be used.

cscript.exe /nologo adsutil.vbs GET W3SVC/AppPools/AppPoolName/WAMUserPass

However, I wanted to write my own little script. Having a little tidbit makes it easy to reuse later for other clients. For example, I could search AD for SPNs starting with “HTTP”, loop through each of their app pools and document the username and passwords for all service accounts used in this fashion. So, here is the little tidbit I threw together.

Option Explicit

Call GetAppPoolUserAndPass("localhost", "ApplicationPoolName")

Private Sub GetAppPoolUserAndPass (byVal strComputer, byVal strAppPool)
	Dim appPool
	On Error Resume Next
	Set appPool = GetObject("IIS://" & strComputer & "/w3svc/AppPools/" & strAppPool)
	If Err Then
		wscript.echo "Error connecting to " & chr(34) & strAppPool & chr(34) & " on " & strComputer
	Else
		wscript.echo strAppPool & vbTab & appPool.WAMUserName & vbTab & appPool.WAMUserPass
	End If
	On Error GoTo 0
End Sub

Here is an example of just what I mentioned above. YMMV but this should discover IIS boxes and report all the accounts used in their app pools. Note: Pools using built-in accounts will show up with blank passwords; this is normal; the password isn’t actually blank.

Option Explicit

' Determine DNS domain name.
Set objRootDSE = GetObject("LDAP://RootDSE")
strDNSDomain = objRootDSE.Get("defaultNamingContext")

' Determine DNS domain name.
Dim objRootDSE, strDNSDomain
Set objRootDSE = GetObject("LDAP://RootDSE")
strDNSDomain = objRootDSE.Get("defaultNamingContext")

' Use ADO to search Active Directory.
Dim adoCommand, adoConnection
Set adoCommand = CreateObject("ADODB.Command")
Set adoConnection = CreateObject("ADODB.Connection")
adoConnection.Provider = "ADsDSOObject"
adoConnection.Open "Active Directory Provider"
adoCommand.ActiveConnection = adoConnection

' Build Query
Dim strBase, strFilter, strAttributes, strQuery
strBase = ""
strFilter = "(servicePrincipalName=HTTP*)" 'Search for SPN starting w/ HTTP (case insensitive)
strAttributes = "name"
strQuery = strBase & ";" & strFilter & ";" & strAttributes & ";subtree"
adoCommand.CommandText = strQuery
adoCommand.Properties("Page Size") = 100
adoCommand.Properties("Timeout") = 30
adoCommand.Properties("Cache Results") = False

Dim adoRecordset
Set adoRecordset = adoCommand.Execute

If (adoRecordset.EOF = True) Then
    Wscript.Echo "No SPNs Found matching HTTP*"
    Wscript.Quit
End If

Wscript.Echo "Computer Name" & vbTab & "AppPool Name" & vbTab & "User Name" & vbTab & "User Password"

Do Until adoRecordset.EOF
    Call GetApplicationPools(adoRecordset.Fields("name").Value & "." & strDNSDomain)
    adoRecordset.MoveNext
Loop
adoRecordset.Close

' Clean up.
adoConnection.Close

Private Sub GetApplicationPools (byVal strComputer)
	Dim objWMIService, colItems, objItem
	
	On Error Resume Next
	Set objWMIService = GetObject("winmgmts:{authenticationLevel=pktPrivacy}\" & strComputer & "rootmicrosoftiisv2")
	Set colItems = objWMIService.ExecQuery("Select * from IIsApplicationPoolSetting")
	If Err Then
		wscript.echo "Error connecting to " & strComputer
	Else
		For Each objItem in colItems
			Wscript.Echo strComputer & vbTab & objItem.Name & vbTab & objItem.WAMUserName & vbTab & objItem.WAMUserPass
		Next
	End If
End Sub

The Power of Scripting: Finding Morto.A

Here I go on another vbScript tutorial.  You might ask why I’m not doing this in powershell yet and it is simple: I still run into 2003 and XP environments. Oh yeah, and this works. I don’t care what scripting language I’m writing in if it gets the job done; you shouldn’t either. My $0.02. If you want to download this script, click here: Morto.A Detection Script.

A had to do a little cleanup on a network from the Morto.A worm.  The first thing I wanted to do was find out how bad things were.  They were reporting a DDOS across their LAN (mostly 3389) and a lot of other issues.  It as obvious we were going to need to rebuild a few systems but we wanted to get a grasp out of what the damage was.  This were generally working: logons, shares, etc.

I’m not going to go over what we did on the firewall or local network but discuss a quick script I threw together to scan the network for infected systems.  The trick was this network had multiple domains and several computers that weren’t even domain joined.

So, I put my automation hat on and threw together a script I will outline below.  I split this into sections to help you see how you can use scripting to piece together a complicated job in simple tasks.  It is pretty basic.  I start by defining what I want to do:

Problem statement: I need to check every computer in each domain for infection of the Morto.A worm.  I can split this into three distinct steps:

  1. For Each Domain
  2. Get Each Computer
  3. Check for Morto.A

For Each Domain

This is pretty simple.  There are advanced techniques for finding all the domains in a forest or reading from a text file or even a spreadsheet.  I like to keep it simple and just create an array.

Dim arrDomains
arrDomains = Array("domain1.domain.local", "domain2.domain.local", "domain3.domain.local")
For Each Domain in arrDomains
	Call ComputersAll(Domain)
Next

Get Each Computer

Now, I need to build the “ComputersAll” sub-routine.  I call this in the domain script by passing each domain in DNS format.  I used DNS domains in my example on purpose (you could use the DistinguishedName format “dc=domain1,dc=domain,dc=local” but I prefer DNS names for this purpose).  By default, each computer in that domain is going to register itself in DNS (assuming you set it up properly).  I want to get the computer name out of AD and append the dns domain name.  Once that is done, I want to use my “IsConnectible” script to check and make sure it is online.  If it pings, I should be able to carry out my business and find out if it is infected.

The real magic is in the lines: strBase, strAttrs and strFilter.  strBase sets the search base to the domain you sent the sub-routine.  It isn’t going to go outside this domain for its search but it will search the whole domain due to its use of subtree.  The search a specific OU, you have to use the DN format and that is out of scope of this article.  The strAttrs is pretty straight forward.  This is an array of attributes you want returned.  You could do DNSDomainName but some clients set this improperly.  It is safe to assume (in most cases) that the name and the domain name comprise the DNS domain name.  The strFilter isn’t doing much but may look complex.  Basically, it is looking for computers in AD that aren’t disabled.

The other things to pay attention to is the line after

Do Until ADORecordSet.EOF

.  This checks first if the computer is on the network through my “IsConnectible” script.  It passes the FQDN by appending “.” and the domain name to the name attribute from the query.

Const adUseClient = 3
Private Sub ComputersAll(byVal strDomain)
	Set adoCommand = CreateObject("ADODB.Command")
	Set adoConnection = CreateObject("ADODB.Connection")
	adoConnection.Provider = "ADsDSOObject"
	adoConnection.cursorLocation = adUseClient
	adoConnection.Open "Active Directory Provider"
	adoCommand.ActiveConnection = adoConnection

	strBase   =  ";"
	strFilter = "(&(objectClass=computer)(!userAccountControl:1.2.840.113556.1.4.803:=2));"
	strAttrs  = "name;"
	strScope  = "subtree"
	strQuery = strBase & strFilter & strAttrs & strScope
	adoCommand.CommandText = strQuery
	adoCommand.Properties("Page Size") = 5000
	adoCommand.Properties("Timeout") = 30
	adoCommand.Properties("Cache Results") = False

	Set adoRecordset = adoCommand.Execute

	If adoRecordset.RecordCount > 0 Then
		' wscript.echo "Computers for " & strDomain & ": " & adoRecordset.RecordCount
		' Loop through every single computer in the domain
		adoRecordset.MoveFirst
		Do Until adoRecordset.EOF
			If IsConnectible(adoRecordset.Fields("name").Value & "." & strDomain) = "Online" Then Call DetectMorto(adoRecordset.Fields("name").Value & "." & strDomain)
			adoRecordset.MoveNext
		Loop
	End If
	adoRecordset.Close
	adoConnection.Close
End Sub

Check For Morto.A

This is the tricky part. I used several sources and found two distict characterisitcs of this work:

  1. C:windowssystem32sens32.dll
  2. HKLMSystemWPA
    1. Key: sr
    2. Value: Sens

So, I need to check and see if a file and registry key exists in order to detect if the machine is infected.  There are a couple of caveats with this: 1) when checking if a file exists, the default response is true on error, 2) you need local admin rights to query the c$ share, and 2) the registry check relies on the remote registry service.  To overcome these caveats, we put error checking in.  If an error occurs, it assumes a manual check is needed.  We do this to err on the side of caution.  Of course, on a large network, this isn’t desirable.  Feel free to contact me if you need more advanced help.  Here is the sub-routine I came up with to do all of the above.  It is mean and nasty and isn’t exactly the kind of finesse I prefer but, it works…

First, I try writing a temp file (and deleting it if it succeeds). If that works, I should be able to detect if the file exists and connect to the remote registry. However, perhaps you are an admin that is paranoid and disables the remote registry service. Well, it will still detect an error and tell you to check manually. Of course, if you don’t have admin rights, it will also tell you to check remotely.

Private Sub DetectMorto(byVal strComputer)
	' Detects morto via several methods...
	Dim blnInfected : blnInfected = False
	
	
	' Requires admin rights to properly detect. Check for rights
	Dim objFSO : Set objFSO = CreateObject("Scripting.FileSystemObject")
	On Error Resume Next
	Dim TempFile : Set TempFile = objFSO.CreateTextFile("\" & strComputer & "c$WINDOWStempfile.deleteme", True)
	TempFile.WriteLine("This is a test.")
	TempFile.Close
	Set TempFile = Nothing
	objFSO.DeleteFile("\" & strComputer & "c$WINDOWStempfile.deleteme")	
	If Err Then bnlInfected = "Error"
	Err.Clear
	On Error GoTo 0
	
	' Check for registry key placed by Morto...
	Dim strKeyPath, strEntryName, objReg, strValue
	strKeyPath = "SYSTEMWPA"
	strEntryName = "sr"
	On Error Resume Next
	Set objReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\" & strComputer & "rootdefault:StdRegProv")
	objReg.GetStringValue HKEY_LOCAL_COMPUTER, strKeyPath, strEntryName, strValue

	If Err Then blnInfected = "Error"
	If strValue = "Sens" Then blnInfected = True
	
	' Check for file indicating morto infection
	Dim strMortoSens32
	strMortoSens32 = "\" & strComputer & "c$WINDOWSsystem32Sens32.dll"
	If objFSO.FileExists(strMortoSens32) Then blnInfected = True
	
	' If the Infected flag is set, it is infected...
	If blnInfected = True Then
		wscript.echo "*******MORTO INFECTION: " & strComputer
	ElseIf blnInfected = "Error" Then
		wscript.echo "Error (Check Manually): " & strComputer
	Else
		wscript.echo "Clean: " & strComputer
	End If
End Sub

Conclusion

So, I have taken several scripts and thrown them together to find a solution. I can reuse this for anything. Perhaps I want to use vbscript to find computers with a certain file on their hard drive. I can reuse this by just tweaking the Morto sub-routine.

Part 3: Blocking Bad Hosts – Blocking Them, Easily (CLI Edition)

In part two, I showed you how to use the Local Security Policy GUI to block the bad guys. There were a lot of pretty pictures for those that prefer the GUI. In this version, I’ll show you how to accomplish the same thing from the command line. This is my preferred method.  It is much simpler to automate and explain.

By following the steps below, you will be able to create a new policy and manage the filter lists and actions. The goal here will be to put all these pieces together into a nice tidy package that is fully automated. Read more

Part 2: Blocking Bad Hosts – Blocking Them, Easily (GUI Edition)

In part two, I want to show how you can quickly setup an ipsec policy to block the bad hosts you identified in part one. While many methods can be used to block hosts, using the Local Security Policy (secpol.msc) and ipsec is a simple method which can be fully automated.

By following the steps below, you will be able to create a new policy and manage the filter lists and actions. In part three, I will explain how this can be done from the command line for all you CLI warriors. This tutorial should be accurate for: Windows XP, Vista, 7 and Server 2003, 2008, 2008R2 (possibly even 2000) Read more