Windows Service Accounts - Why They're Evil and Why Pentesters Love them!

Published: 2015-08-12
Last Updated: 2015-08-13 13:04:58 UTC
by Rob VandenBrink (Version: 2)
14 comment(s)

Windows Service Accounts have been one of those enterprise "neccessary evils" - things that you have to have, but nobody ever talks about or considers to be a problem.  All too often, these service accounts are in the Domain Admins group, with passwords like "Service123", "S3rvic3" or something equally lame.  And all too often, application vendors that use these services insist on just such a configuration.

Why is using actual service accounts a bad thing?  Aside from the fact that the passwords are generally set to never change, the passwords are stored in the registry, in a text format that is easily captured to arrive at the actual password.  Needless to say, this generally allows an attacker to fly under the radar and move laterally to other hosts - pillaging your AD Domain at will.

So, how do we find these service accounts?  It's the same method, whether you are doing this to protect your assets, or if you are in a Penetration Test or Security Assessment.  List all the services for all stations in the domain, and winnow out the ones that have service accounts (either local or domain) attached to them.

In days gone by, I would have used WMIC:

First, look at "getservices.cmd":

REM one or both of
netdom query server | find /v "List" > targetlist.out
netdom query workstation | find /v "List" >> targetlist.out

for /F "tokens=1" %%S in (targetlist.out) DO call servicelist.cmd %%S  >> services.out

type services.out | find /v /i "LocalSystem" | find /v "LocalService" | find /v /i "NetworkService"

where servicelist.cmd looks like:

wmic /node:%1 service get systemname,displayname,started,startmode,Startname

This will give you a list of all services that use local or domain accounts, what machines they are installed on, if they are running and if they are enabled, disabled or set for manual control.  However, this takes **forever**, especially the netdom command!  How can we do this in Powershell?

Enumeration Again - with Powershell:

So, if you've used the  WMIC approach to recover windows Service account information in a reasonably sized AD Domain, you've likely found it to be is a very sl-o-o-o-w process - we'll see that it runs much faster using Powershell.

First, let's try the "Get-Service" cmdlet.  

get-service -computername $TARGET | format-list
Name                : WwanSvc
DisplayName         : WWAN AutoConfig
Status              : Stopped
DependentServices   : {}
ServicesDependedOn  : {PlugPlay, NdisUio, RpcSs, NlaSvc}
CanPauseAndContinue : False
CanShutdown         : False
CanStop             : False
ServiceType         : Win32ShareProcess

We see here that get-service doesn't give us service account login information - in fact it doesn't give us a lot of things about the services that you'd expect to see.  What to do?  Use WMI within Powershell!

get-wmiobject win32_service -computername $TARGET | format-table systemname, displayname,startname, state

How do we then link this up to a list of computers in the domain?  Use the Get-ADComputers cmdlet of course!  (You might need to run "import-module activedirectory" on older systems)

So, linking it all together in a one-liner:

get-adcomputer -filter * | foreach { Get-WmiObject Win32_service -Computer $ } | select-object systemname, displayname,startname, state | export-csv services.csv

Will get you the list of all services on all hosts in the domain.  I normally grab the entire list, then filter it, just as in the WMIC example, to find our  "problem" services, the hosts that they're running on and especially the service accounts that are in use:

type services.csv  |  find /v /i "LocalSystem" | find /v "LocalService" | find /v /i "NetworkService"

Fixing the Problem
Microsoft has come up with a decent way to mitigate this issue.  Where possible, have your services run as "LocalSystem", "NT AUTHORITY\LocalService" or "NT AUTHORITY\NetworkService"
These settings are run levels for services only (they can't be used for interactive login), with differing security permissions, but NO PASSWORD.  What this means is that the service has the authority that it needs, but there isn't a password to crack, and the account can't be used for a normal interactive login session.

Tools like Metasploit can of course be used to run processes on a target (compromised) host with these privilege levels, but this service account approach is still way better than using actual accounts with real passwords.

If you've got a "neater" way of enumerating service accounts, especially in Powershell, please use our comment section - we'd love to hear from you!

Rob VandenBrink

14 comment(s)

Yes Virginia, Stored XSS's Do Exist!

Published: 2015-08-12
Last Updated: 2015-08-12 21:40:10 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

When you go through website security, Cross Site Scripting (XSS) is almost always discussed.  Almost exclusively, Reflected XSS is the main topic, and it almost always covers the lion's share of the demonstrations and vulnerabilities found.  Mainly because Stored or Persistent XSS is harder to find.

But Stored or Persistent XSS is an actual thing, and it is seen in the wild.  In Stored XSS, data is stored, often in a back-end database, and the act of reading that data at a later time triggers the exploit.

Just this past week (I'm a bit behind, just back from vacation), Apple had a Stored XSS vulnerability in the iTunes and App Stores.  If you named your device in a malicious manner, reading the device name in any subsequent invoices would trigger the exploit.  So what you say - you just exploited yourself.  Ahhh - but the not so obvious piece of this is that you likely also sent the exploit to anyone you purchase any product in the store from (for instance, App purchases).  

There's no good way to know if anyone was actually exploited using this - really it depends on which browser and version they were running at the time.  The bug was found and reported by the folks at Vulnerability Lab, so it's not clear if this was ever seen "in the wild".  However, I'm sure that Apple wasn't thrilled about being a potential transit for malicious activity like this (it's since been fixed of course)

This does make a great example of how a Stored or Persistent XSS can work though - if you need to make the point to a client, someone in management or a developer, this makes a good example to trot out!

If you've seen something similar, a persistent XSS in real live (that you are able to talk about), please share using our comment form!

Rob VandenBrink

0 comment(s)
Wireshark 1.12.7 is released, multiple fixes. Find the release notes at: and the binaries at:
ISC StormCast for Wednesday, August 12th 2015


Diary Archives