April 07, 2019

I'll Be Back - Adding Session Termination to Your IR Plan

CIRP Session Terminator


"I'm Here From the Future"

I wanted to share a recurring issue I run into while doing red team operations against organizations who already have a mature security model and hopefully, offer some easy-to-implement advice to strengthen your Incident Response (IR) efforts.  Perhaps the most important part of what we do in these engagements during the documentation write-up is to provide solid, actionable advice for how to prevent the same type of techniques and "attacks" from being successful in the future.  This specific solution doesn't appear to be common nor is well documented in the community when it comes to Incident Response Plans.  

I'm talking about terminating active sessions of compromised accounts.  Session issues are commonly documented in the Application Security space and are a common scenario when threat modeling.  Session Management Issues such as Session Fixation, Long Timeouts, Not Destroying Properly on Server-Side, and Session Token Mishandling are just a few examples of this.  Although these do an awesome job of limiting the damage a bad actor can do if implemented properly, there needs to be an immediate, reactive action when dealing with a IR scenario.  It's a relatively quick and easy task and it goes a long way in preventing an attacker from having more time to establish persistence in your environment.  Then you can say, (brace for the bad pun) "Hasta la vista, baby!" in your worst Arnold impersonation while feeling better about mitigating the threat of unauthorized use.  If it's Skynet, you have bigger problems.

So what's the problem anyways?  Can't we go back in time and prevent this whole IR situation from happening in the first place?  Um, no.. and frankly I would have expected you to have known that..  But what we CAN do is prepare ourselves with an Incident Response Plan, or enhance an existing one, in case something does happen in the future.  Let me play out a couple of scenarios I've experienced firsthand, where I was the red teamer and was up against a blue team Security Operations Center (SOC).  In both of these situations, I had obtained valid domain credentials from a targeted spear-phishing attack.  It was only a matter of time before my emails were reported and credentials would be reset, so I was racing against time (fully clothed) to maintain an internal foothold.  

Scenario #1

VMWare Horizons & Cisco AnyConnect VPN Access :

I had done my homework beforehand and planned to target two remote administration services.  One being a VPN service and the other, VMWare Horizons, which would allow me to gain access to the VDI environment externally.  I assume other services like Citrix should be on this list as well, but I haven't tested for these purposes.

Soon after receiving valid credentials from a privileged user in the IT Help Desk group, I logged into both the VPN and VMWare Horizon instances.  This user fortunately had privileges on the domain to create new domain users as well as had local administrator rights on the servers and workstations.  Shortly afterwards, I received a Windows notification saying it was necessary to re-enter my credentials!  I've seen this before, and I realized immediately that the user must have reported the incident and the IR playbook was leveraged to reset the credentials for said compromised user.

My first thought was that I was done for, I would have to go back to phishing and start from the drawling board with an already alert blue team.  However, I soon realized that for me to even read that Windows system notification, my VMWare Horizon account must still have an active session in my web browser.  Sure enough, both my Citrix VPN client and my Horizon session were still authenticated.  It was now going to be a race against time, knowing that by default Horizon sessions time out within sixty minutes.

My victim's AD credentials were cached as well and I could still perform certain actions within Active Directory Users and Computers (ADUC), such as create new users!  I would create a new account only to have it "disabled" shortly afterwards by the SOC.  To spare you the long story, I was able to eventually create a new user, add them to the Remote Desktop User's group, and Remote Desktop to the Domain Controller (DC) quickly just before that account was revoked as well.  At this point the SOC was confident they had contained the "attacker", but I was still active on VMWare Horizon, now sitting on the DC with Local Administrative rights over nested RDP connections like a bad inception dream.  From here I was able to steal the NTDS.dit file and get all of the passwords for the organization, which then allowed me to connect with whatever credentials I wanted.

Clearly, this is a problem.  Even though the SOC was quick to detect and respond to the creation of new accounts, and even though the phishing victim's passwords were forcibly changed, I still had enough persistence and time to carry out my escalated attack.

Scenario #2
  
Office 365 Email Access :

I've actually learned from more than one successful red team phishing campaign that sessions by default do not terminate when AD credentials are reset in O365.  Because of this, I'll often authenticate to multiple victim's inboxes in multiple browser sessions as soon as I receive credentials so I can remain logged in even after passwords are reset.  I even trained my penetration testing team so we do this for all phishing engagements now by default.  It is mistakenly believed that resetting user passwords will force the attacker to re-authenticate immediately.  In fact, I've even had IT Administrators taunting me with subsequent submissions to my false phishing portal that their password has been changed.  Something to the tune of, "Nanananana ICHANGEDMYPASSWORDSUCKER!".  To which I smile like Arnold..


"Come With Me if You Want to Live"

So what can we do to protect our systems?  Well it depends on the remote service, but proper session management is key here as a preventative measure.  It's important to make sure that sessions by default are not active longer than necessary and do require the user to re-authenticate after a certain period of time.  This isn't really anything new, but certainly worth bringing up again.  A few of the clients I had worked with extended sessions to the maximum allowed, which just meant without sessions being forcibly terminated I had until my laptop died to move laterally or judgement day arrived, whichever came first.

In these above two scenarios, I recommended to the respective customers that they simply make an addition to their already strong IR plan.  Clearly they were already following a playbook in near-real time to deactivate or reset passwords for compromised user accounts.  My advice is to go all Schwarzenegger and forcibly terminate the sessions as well, that way any lingering access is cut off immediately, without having to wait for the session to expire.

There's a wrong way and a right way to terminate sessions though!  You don't want to terminate the session first and then change credentials later.  This may allow an attacker to jump right back on before the passwords can be reset, landing you in the same situation as before.  However, if you force a password change and then terminate the active session, the attacker has no way to jump back on.  If this would have been done on the engagements I was on, I would have lost any access relatively quickly and it would have been much more difficult to establish persistence.  In these specific scenarios, I would have to start from the beginning all over again and likely meet the same fate each time.

Depending on the service that is being accessed, do some research to see what the quickest and most reliable means is for terminating sessions.  This may be a manual effort, such as having the self-reporting victims of phishing campaigns trained to "Sign Out", or having the Help Desk do it on the user's behalf.  As I think of it, it wouldn't hurt to add this to the employee security awareness training sessions.  This can be a scripted effort in the case of O365 by using PowerShell to force logout everyone on the domain in case multiple users are affected.  Either way, consider adding some sort of session termination action item to your CIRP on your external authentication services.  Otherwise, "I'll be back!" 😎

Thanks again!
Curtis Brazzell

No comments:

Post a Comment