Share this page!

Stephan Berger Profile picture
Twitter logo
Oct 11 • 10 tweets • 3 min read
1/ Perhaps a lesser known "feature" of Microsoft Authenticator, but the diagnostic data can be very helpful in investigating a compromised #Azure account where MFA is enabled but the user claims not to have confirmed the MFA Consent Prompt. 🧵
2/ You will find the diagnostic data here:

Authenticator App
▪️ Burger Menu
▪️ Send feedback
▪️ Having trouble?
▪️ View diagnostic data

Click "Copy all" and send the text via mail or other ways to your analysis device. Image
3/ When logging into an MFA protected (the second factor is the Consent Prompt) account, we see the following entries (abbreviated) in the Authenticator diagnostic data:
4/ 2022-10-09 18:24:48.700 VERB MfaSdk 0 TID=1 0 () handleCheckForAuthResponse(request:error:dosPreventer:currentDeviceToken:previousDeviceToken:):

➡️ Pending authentication found for username: 2c4fa44468@<redacted_domain>
5/ The random looking number above can be mapped to a user within the diagnostic data.

2022-10-09 18:24:51.286 VERB MfaSdk 0 TID=1 0 () -[AuthenticationSessionNotificationBuilder createStandardNotificationAlert:messageText:[..]]_block_invoke_2:

➡️ Approve button clicked
6/ There you have it.

We see in the logs that an authentication or confirmation has been requested and that the user has confirmed it. ✅

The sign-in logs will show that MFA was completed within Azure. Image
7/ In the Authentication Details it also says "Mobile app notification".

The timestamps from the Authenticator App to the Sign-In logs are only a few seconds off, so correlation should not be that difficult. Image
8/ The data from the Authenticator App can be used to prove that a user has given his consent to the MFA prompt, and the attacker has logged into the account that way (the credentials must be known to the attacker, of course).
9/ But with this evidence of the user confirming the Consent Prompt, other attack vectors can be ruled out, which of course also affects the course of the investigation.
10/ @rootsecdev wrote an excellent blog post on how to improve MFA for Azure 💪🏅

trustedsec.com/blog/defending…

• • •

Missing some Tweet in this thread? You can try to force a refresh
　

Keep Current with Stephan Berger

Stephan Berger Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @malmoeb

Stephan Berger Profile picture
Oct 10
1/ @rootsecdev published a blog post where common misconfigurations inside the Conditional Access Policies in Azure are discussed.

In an Azure Tenant from a customer, the following CA policy was implemented: Require MFA for administrative users.

🧵
2/ However, within the Directory roles checkbox, not all the roles were selected (see the picture below).

In Azure Assessments, I use, among others, the script Get-MsolRolesAndMembers.ps1 to find users which are part of such different roles. [2]
3/ The users or roles found with the mentioned script must be cross-checked with the CA (the checked roles from the menu above) to find possible users which could log in without MFA, resulting in a security gap. 🔎
Read 10 tweets
Stephan Berger Profile picture
Oct 8
1/ #ThreatHunting: @Avast has blogged how Roshtyak checks the VBAWarnings registry value.

If the value is 1 ("Enable all macros"), then the code will not be executed because it is assumed that this setting is only enabled in a sandbox (or by courageous users). 🧵 #CyberSecurity
2/ "Interestingly, this means that users, who for whatever reason have lowered their security this way, are immune to Roshtyak." [1]
3/ However, this "Enable all macros" value can also be explicitly set for Outlook

(Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook - Level = 1).

If this value is set to 1 in a user context, a nifty persistence within Outlook may have been set up by a TA.
Read 7 tweets
Stephan Berger Profile picture
Sep 28
/1 Repeat after me: AV scans and password change is not enough after a full AD compromise.

A company has already been encrypted twice and asked us for a second opinion. The responders did a password change with an AV scan of the machines...

What could possibly go wrong? 🧵
2/ @UK_Daniel_Card has compiled a good checklist that gives an insight into the many different tasks that are part of a proper IR engagement or clean-up (list not exhaustive):

pwndefend.com/2021/09/15/pos…
3/ Another point missing on the checklist is the hunting for "legitimate" remote desktop solutions installed by the TA, which could be used as a backdoor for re-entry (Atera, Splashot, AnyDesk..).
Read 4 tweets
Stephan Berger Profile picture
Sep 27
1/ While analyzing AutoRuns entries in a Compromise Assessment, my teammate @newtt42 found four executables with different names but with the same hash (in the C:\Windows directory).

The binaries were ran as services with the following names: JXds, vdEp, JXmM, PTLt. 🧵
2/ @Synacktiv has published a blog post recently where our observations are described:

"The SysInternals PsExec starts a service that is named PsExeSvc by default whereas Impacket's psexec.py tool spawns a process with a randomly generated 4-characters name." [1]
3/ We can hunt for such binary and service names using this sigma rule [2]:

ImagePath|re: '^%systemroot%\\[a-zA-Z]{8}\.exe$'
ServiceName|re: '(^[a-zA-Z]{4}$)|(^[a-zA-Z]{8}$)|(^[a-zA-Z]{16}$)'
Read 5 tweets
Stephan Berger Profile picture
Sep 25
1/ #ThreatHunting: Normal users (not developers) who have Python in their Music (!) directory? This screams TA 😅

In an investigation on a breached network, we discovered the following directory:

C:\Users\<user>\Music\WPy64-39100\python-3.9.10.amdMusic\WPy64-39100
2/ The funny thing is that the TA appended "Music" to the ordinary directory name "python-3.9.10.amd64" to make it look more legitimate?

In several directories, we found attack scripts (written in Python), including noPac.py

(github.com/Ridter/noPac)
3/ And the whole impacket suite.

(github.com/SecureAuthCorp…)

Monitoring or creating a baseline (which users are using Python) could be helpful here, or just monitoring from which paths Python is started (like in our example from the Music directory).
Read 5 tweets
Stephan Berger Profile picture
Sep 23
1/ #ThreatHunting:

In a compromised network, the TA used PCHunter on different systems to disable the local AV (or at least tried it).

In the web requests recorded on the firewall, we found traces of the download:
www.epoolsoft[.]com/pchunter/pchunter_free

🧵 #CyberSecurity
2/ @CrowdStrike also mentioned PCHUnter in the latest ThreatHunting report, along with GMER.

go.crowdstrike.com/rs/281-OBQ-266…
3/ I have tweeted about two of these tools (PCHunter / GMER) before, and we also see these two products regularly in our IR cases.

Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

Send Email!

Email the whole thread instead of just a link!

Separate emails with commas

:(