PowerShell

Webinar – 5 Key Issues Uncovered During Incident Response

Changes

I have changed direction of work, for a long time now, I have been working in Truesec CSIRT (Cyber Security Response Team), and my job is to recover/rebuild the customer environment after it has been ruined for various reasons, most of the reason is cyber attack’s and ransomware. But, it also means that I use my “bunny” skills, since redeployment is one of the tasks I do Smile

Last year my team conducted over 35.000 hours of forensic investigation and recovery work, with amount of work, we can “see” certain patterns, we can see where customers have weaknesses, so we deiced to run a webinar on that topic, here is a short summary of the content, including the scripts that was used during the session.

Here is the link to the event:
https://event.truesec.com/webinar-incident-response-issues-1-nov-2023

Here is the link to the sample files:
https://github.com/DeploymentBunny/Files/tree/master/Tools/IdentityLifeCyleWoops

Here is the short summery of the content

Identity Lifecycle “woops”

The lack of identity life cycle is something we see very often, we see that many accounts never change password, sometimes up 10 years or more, service accounts being domain admin, etc.

You should clean up every directory you have regularly, (monthly – yearly).

  • Disable accounts, don’t remove
  • Set new password
  • Set require to change at next logon
  • Remove password never expiree
  • Remove Password Not required

If you have Defender for Identity, you can set disabled accounts as a “honey Token”, that way you get notified if someone is trying to use it.

Let us look at some scriptsimage
With just a small script you can see all the accounts that are enabled, have password never expires and the last time they logged on, some accounts has not even been used, and never changed password.

Next sample
image
Here we can see all the ´members of the Domain Admin group, a group that should be almost empty, in this case it is not, and many accounts has not changed the password in years, this is bad.

Next Sample
image
Here we can see all the accounts that have the adminflag set to “greater then 0”, that means that all these accounts has been or are current members of some form of administrators group, all these accounts are high value targets for threat actors, they should be secure or disabled and change password on a regular basis.

Administrative Interface Isolation

I cannot stress this enough, but your hypervisors, SAN, network equipment, etc should be “isolated”, it means that it should be impossible from any regular network to access any of the items directly. We call this “fabric isolation”, it means that the hypervisors runs in a separate domain, separate network in a dedicated domain (if it is hyper-v, if it is VMware, it does not need a domain).

The time it takes for the threat actor to destroy the VMware or Hyper-V environment after getting access is minutes, and the all is gone. We see this every week, yes every week…

Avoid integrating Ilo/Idrac with SSO with the Active Directory that all users exists in, use a dedicated domain for that, or use local passwords (not the same!!!), and the same goes for your hypervisor, it should not be possible to access your vCenter from everywhere, and it should not be possible to logon using the Active Directory credentials(unless that is a separate Active Directory used for Fabric and nothing else.

Think of Ilo/Idrac/Hyperv/vCenter as the virtual server room, it should be different authentication to get trough the door, once you are on the inside, there is no protection left, with keyboard access you can do whatever you want.

Here is one way to become admin when you need
image

Next step
image

Nothing new, this has worked for a long time and is well known.

Administrative Account Exposure

This is also an issue, each time you use your admin credentials, you are at risk of someone stealing them from you, things like

  • Pass the Hash
  • Pass the Ticket
  • Pass the Token

And you need to understand how to minimize the risk, in theory that is easy

  • Limit the number of times
  • Limit the number of locations
  • Limit the number of devices
  • Limit the number of Admins

When you boil it down, it means use Administrative tiering to protect the control plane and automate as much as you can.

(You can watch Peter Lofgren in this video that explains Tiering https://www.youtube.com/watch?v=OPwR2UFDYR0&t=1s)

The basics of tiering is to prevent the administrator to logon to the wrong tier and allow to logon to the correct tier, tiers are usually divided in to three tiers

  • Tier 0 = The control Plane, this “Keys to the Kingdom”
  • Tier 1 = Servers that are not in Tier 0
  • Tier Endpoint = All clients

Being in a tier does not automatically give you access to everything, the point is to block you from trying to access the wrong tier, this is done using GPOs, there are many settings but these are the most important.
image

Ransomware Deployment Protocol, also knowns as RDP

RDP is a fantastic protocol, it was and are designed for users, it was never intended for administrators, in the beginning it was stated by Microsoft that “Using Remote Desktop Protocol is a last resort to be able to control a server, do not use it as your standard administrative tool”, the reason? It uses CredSSP to solve the double hop issue, but that also means that the server stores your credentials, that also means that anyone with admin access to that device, can “borrow” your identity, and there is no way for you to be sure that that devices is safe before you logon…so, RDP is great for the threat actor, but not always a great idea for you.

So, what should you use instead, that is easy, use something that does not expose your credentials, like

  • Remote PowerShell
  • Remote Server Administrative Tools
  • Windows Admin Center
  • Azure Arc

All this is far better than using RDP, and the sad thing is that on many of the victims we work on, PowerShell is blocked, Firewall is Of and RDP is enabled, the exact opposite to secure.

But, hey, you need RDP for older systems, in that case configure your systems for Restricted Admin Mode, that will not exposé you as bad as native RDP, here is the link on how to configure it https://social.technet.microsoft.com/wiki/contents/articles/32905.remote-desktop-services-enable-restricted-admin-mode.aspx

Backup is your last line of defence, protect it

The last part is the backup, all the victims have a backup solution, but it only work in around 25%. The reasons are: misconfiguration, never tested, have no idea how it works, unsupported, lost the encryption keys, etc., the list is long, and they all said the same thing “We thought it was a great solution…

here are some notes to remember.

  • Agent should run as Local System
    • running as domain admin is extremely dangerous, and very common
  • Backups should be encrypted (by you)
  • Backups should be tested
  • Backups must be supported for
    • Active Directory
    • SQL/Exchange/ApplicationXYZ
  • One-Way
  • Off-Site
  • Immutable

The number of times where we restore a Domain Controller and Active Directory is busted, I cant even count it, we spend hours/days to repair/recover it after restore, and the reason? The backup is just a simple snapshot backup that does not support Active Directory.

Until next time

/mike

Categories: PowerShell, Security, TrueSec

Tagged as: , ,

4 replies »

  1. The link to the webinar gives a “404 – page not found” error. Can you update with a corrected link? Other than that, this is great information. Thank you for passing this along.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.