One of the most helpful concepts for administration of your tiering-segmented environment is priorizing passwordless administration (SSO). A crucial part of the puzzle is remote credential guard, another is windows admin center. They make daily administration tasks a lot easier and bring our customers one step closer to full passwordless administration.
Interested in how this works? Get in touch….
Der Treffpunkt für Cyber-Attack & Defense in Westösterreich
Link zur Registrierung: 4. Security-Roundtable in Tirol
Ich darf herzlich zum 4. IT-Security-Roundtable der Strong-IT mit gemütlichem Griller im Anschluss einladen! Die Vorträge werden zusätzliche auch Online übertragen.
Datum: Fr. 08.10.2021 13:00
Ort: SoHo2 Veranstaltungsraum OG4 (Grabenweg 68 – Innsbruck)
Parken: Inhouse Tiefgarage
Kosten: Keine
Vorträge:
ab 18:00 gemütlicher Ausklang bei Wein, Bier und Gegrilltem
Update 2021-03: wir haben inzwischen unseren Bedarf an Neupersonal im Bereich „Security Architect“ gedeckt. Sollte der geneigte Leser der Meinung sein, trotzdem im Bereich IT-Security bei Strong-IT mitwirken zu wollen, freuen wir uns immer über eine Initiativbewerbung.
Kennwort zu kurz. Lokale Adminrechte durch eine Fehlkonfiguration. Domain-Admin als Service Account. Ungehindertes Laterales Movement mit WMIC. Netzwerk nicht segmentiert. Excel als Password Safe. GPO-Backdoor. SMBv1 Schwachstelle nicht geschlossen…
Schon Erfahrung mit diesen Begriffen?
Wir helfen unseren Kunden, moderne IT-Security greifbar zu machen. Wir entwickeln Angriffe, beweisen Resultate und machen die Wirksamkeit von Maßnahmen gegen gezielte Cyberangriffe nachvollziehbar. Sowohl durch Technik, Organisation als auch durch Training.
Unsere Anforderung:
Wir bieten:
Kontakt: bewerbung@strong-it.at – https://www.strong-it.at
Für diese Position beträgt das Jahresbruttogehalt mindestens 50.000 EUR. Darüber hinaus bieten wir grundsätzlich eine marktkonforme Überzahlung abhängig von Ausbildung, beruflicher Qualifikation und Erfahrung.
Ich darf herzlich zum 3. IT-Security-Roundtable der Strong-IT und anschließende Penthouse-Party (dank Corona leider nicht) einladen!
Agenda
14:00 Registration
14:15 Attack: Unhooking your protections
15:00 Coffee Break & Diskussion
15:15 Mitigate: LSASS Protection vs Credential Guard
16:00 Coffee Break & Diskussion
16:15 Detect: SIEM – Finding the needle in the needle stack
17:00 Coffee Break & Diskussion
17:15 Workshop: DPAPI Exfiltration
18:00 Ende
Wir freuen uns auf eure Teilnahme!
Datum Und Uhrzeit
Fr. 2. Oktober 2020
14:00 Uhr – 18:00 Uhr MESZ
Ort:
SoHo 2 – Restaurant Ortiz (EG)
Grabenweg 68
A-6020 – Innsbruck
Parken in der SoHo2-Tiefgarage
(Auf Wunsch auch online)
Mittwoch, 30. Oktober 2019
10:00
In the past couple of days we took a detailed look at how windows hello for business works. We wanted to see how it can be implemented in a domain infrastructure, it’s usability, but most importantly, if it is the hot new security feature you should have implemented already yesterday.
From a pentester perspective, this whole adventure could be summarized with the words „a hash is a hash….“ but hold your horses, there is more to that. Let’s start from the beginning:
WH4B comes in four flavours, you can either go hybrid or stay on-premise, and there is the technical decision to either utilise an existing certificate authority infrastructure or go without. We opted for variant 4: on-premise with certificates, which also allows to initiate RDP connections with WH4B – and that seemed like a nice feature. Also the decision was made to do face recognition instead of fingerprint.
The documentation https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-deployment-guide is a little sharp around the edges, and i made some suggestions for improvement in the comment sections. But with a little dedication and a couple of sleepless nights it was possible to get the infrastructure up and running, which in our case consists of:
This is for a small 4-5 guy office. If WH4B is to be implemented in a real enterprise, a minimum of 2 federation servers plus loadbalancer, as well as two proxies should be installed. Just keep that in mind.
The first major issue i ran into was that the device you want use for WH4B has to be registered with the device enrollment service on the AD FS server. It took me a while to figure out that the DSREGCMD.exe which handles the registration (and also can be used for debugging tasks) can be called by a normal user account, but will produce wrong results because it has to be execute in a SYSTEM context (yes, we’re talking about psexec -i -s cmd.exe here). Additionally, the documentation was lacking an instruction for device auto enrollment GPO settings.
Anywho, the takeway here is: before you even try to register your face for WH4B, the device needs to be enrolled and this entire process has to work automatically in the background without user intervention.
The second issue that crept up was that once the device is enrolled, and the user is prompted to enroll for WH4B the system asks for a „second factor“ to verify that the person smiling into the laptop camera is actually me. Since this was a demo setup, and we didn’t want to implement an additional real MFA provider i chose to utilise the „certificate“ option to verify that „me is me“. What i didn’t get right at this time was that i needed an actual, already existing certificate for this step, in my user certificates store. I thought that WH4B would create this for me in the enrollment process, because there is a similarly named certificate template that you have to create during the PKI setup phase.
After understanding the semantics it worked fine. The takeway is that you need some kind of MFA to register for WH4B and if you chose „certificate“, it has to be an already existing one.
Finally, and this is the one that kept me awake a full night (because … who needs to sleep when there is an error message to depuzzle?!), was an actual error message in the last step of the enrollment process: once you made your fake smile to the camera and it would register your biometrics data, a new screen pops up asking for an emergency pin. This has to be defined by the user so if, for example, i had an accident and the camera would no longer recognize me, i could still use the pin to login. Or maybe i was out for a night with the boys, and drank too much, and couldn’t look straight…. Well, you get the idea.
For some reason, registering the PIN created an error message and the process had to be reset and started from the beginning.
I made it work eventually with a powershell command (Set-ADFSProperties -IgnoreTokenBinding:$true). Please don’t ask what this does. It just made the magic happen and let me register my backup pin. (clarification with MS pending…)
In summary, it is working as advertised and is highly convenient. After the rather painful setup process, everything was working well. I smile into the camera and the system logs me in. Done. This is both fast and convenient, and so far i was not able to fake it (e.g. different person looking into the cam, printed photos, etc…). I had one unintended login, where i was too close to the cam but looked somewhere else entirely, and the system would still log me in. I did not yet have a failed login.
RDP is also interesting, because if i chose to terminal server the hell out of my infrastructure, a straight look into the cam instead of typing my highly complex 14-character-password is quite a timesaver. In reality we do have a 3-tier-segmentation in place so i’m actually not really able to RDP around a lot with my normal user account. But more on that in a second.
The most interesting question obviously. And i don’t mean „is WH4B itself secure“. It boasts to be the highest level of security with all kinds of buzzwords like „asymetric tpm backed key encryption voodoo“. This is all fine, and i trust the technology. The biometric data doesn’t leave and is bound to your device.
What we were really wondering before doing this implementation: is there anything different in the domain environment, especially in terms of lateral movement? Are there still NTLM hashes and kerberos tickets, and can they be stolen and re-used? After all, just because you implement WH4B, the rest of your infrastructure doesn’t change: you still have your legacy, NTLM dependent software, the product that doesn’t support SSO, or the server where you intentionally turn it off on purpose, and the login that doesn’t know about kerberos but asks for your password in a web browser popup.
Does WH4B magically do away with all that, and allow face logon through the cam in a new, highly secure way?
Of course not. The painful reality is that NOTHING in your domain has changed. We mimikatzed the hell out of my account and laterally moved like there was no tomorrow.
On stackexchange i posted a question to verify this situation, and „kind of“ got it confirmed by a guy from the WH4B team. He argues a bit differently, and i would like to explain his viewpoint here:
If you want to implement WH4B in the most secure way, then you need to make sure the user doesn’t even know the account password any longer. He/she will login with biometrics, and all the systems in the enterprise have to support SSO, so there will never ever be a popup window asking for credentials. And when the bad guy comes along sending a phish mail, the user will not be able to lose his/her credentials to the attacker, because he/she just doesn’t know the password.
Pass-the-hash and pass-the-ticket are still possible, but should anyway already be mitigated with other technologies (like credential guard). This is not WH4B‘ responsibility.
In reality, i can see how this might work for your average employee. But it will definitely not work in IT. If you take your IT seriously, you will have 3-tier-admin-segmentation in place, like i mentioned above. This alone makes it impossible to utilize WH4B – how should the computer decide if i want to login my server admin account or my normal user acccount, just by looking into the cam? Do i raise the left eyebrow for „server admin“ and the right one for „domain admin“ ? just kidding.
This is what microsoft more or less describes in their „passwordless strategy“ document: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/passwordless-strategy
So: WH4B should be understood as both a technology, and a concept requiring a multitude of changes in an enterprise. The final result is „not knowing a password means it cannot be stolen„. If the attacker is already in the system, then „a hash is a hash„, and nothing has changed.
Happy face unlocking!
If you are on the blue team, you’re most likely aware of the powershell script „NetCease„. It’s a handy tool to harden the default permissions for net session enumeration over smb in such a way that normal domain user rights are no longer sufficient to query for users who have a session open with a fileserver. It essentially modifies a registry setting which contains an ACL in binary format. Details on the NetCease script page.
The scripts effect can easily be verified by manually running „netsess.exe“ against a target system. A successfully hardened box should no longer return session information, unless queried by a user with admin rights on the target.
Since we use bloodhound in both our red teaming and blue teaming engagements extensively, i wanted to gain better understanding on how this hardening method is effecting the session collection procedure. Does NetCease have any effect on session collection at all? According to several sites [1] [2] it should – but we have not yet seen any impact at our customers environments, and what worried me even more, in our own prod and lab environments i was completely unable to reproduce the hardening method’s promised effects.
As you can see below, we gained session information in bloodhound for server SRV007CM, altough netsess.exe failed to retrieve this information.
So where is this data coming from? The domain controller maybe? Let’s harden this one too:
Still, no dice. Bloodhound again knows i’m having sessions open – picture omitted, as it’s the same result as above….
Time for an in-depth investigation!
There are two relevant methods in bloodhound’s ingestor: Session and LoggedOn. The ingestor, when started without optional parameters, or with the specific parameter „Session„, does a smb session enumeration by default, similar to the method used in netsess.exe. When run with the optional parameter „LoggedOn„, or „All,“ it runs two additional collection methods. One is calling an API named „NetWkstaUserEnum“, but it requires administrative rights on the target. It also tries to connect to the target via remote registry, this is where it gets interesting. But step by step.
When we harden a box with netcease, this is how wireshark sees the traffic. You will notice WERR_ACCESS_DENIED for a call from netsess.exe and „Unknown DOS error“ for a call from bloodhound.
In a non-hardenend environment, trying to enumerate sessions with netsess.exe and bloodhound the result looks like this:
In this case netsess.exe reveals this information:
And the data captured with the ingestor then looks like this:
This needs a little explanation. We have queried the server SRV007CM for session information, but bloodhound shows us results for two users on two clients (PC002, PC006NB2), while the server in question doesn’t even show up in the results. Any interactive sesssions (RDP) on the server are not shown. Why is that? The answer is that „HasSession“ is probably just an ill chosen naming convention if you look at it from a protocol perspective. The users in the picture have SMB sessions to the server, but what bloodhound means with „HasSession“ is an actual logon (like interactive or RDP) to a machine. A better name would be „IsLoggedOn“ or something like that.
Regardless of the name: what we see in the GUI is correct – these users are logged on to their workstation, and we have no information what is going on actually on the remote server, because this is not something we can query with net session enumeration.
All of this was quite confusing to me first, but hopefully this clears it up for you too.
As mentioned above, there are two additional methods in the ingestor, which have to be triggered manually (via „LoggedOn“ or „All“ parameter). Let’s ignore NetWkstaUserEnum for now, it requires admin rights on the target, and focus on the remote registry method. What it does is, it tries to connect to the remote registry service of the target, and enumerate HKEY_USERS. Based on the sub-keys it finds, it deduces who is logged on to this box. Contrary to what’s documented on the bloodhound website, this does not require admin rights, in fact it seems to work by default for any user in the domain. Let’s verify this in our lab:
Wireshark shows remote registry traffic going on, let’s try this manually from an unprivileged user, opening regedit.exe and connecting to the remote system:
Success! We were able to query logged on user information on the remote system.
The finding that this works out of the box with default permissions for any user in the domain was quite amusing even for the bloodhound slack community:
Anyway, all of this now explains the question in the introduction paragraph nicely – why does bloodhound show countless session data, although net cease hardening is in place? The answer is simply that it runs an additional data collection method which completely ignores net session enumeration, but is based on remote registry calls, which (at least to my findings), work out of the box for any user in the domain.
Ein herzliches Dankeschön an die zahlreich erschienen Teilnehmer! Dank kühlem Bier und spannenden Vorträgen war der Meeting-Room trotz sommerlicher Temperaturen bis zum Ende des Events gut gefüllt. Wir freuen uns auf das nächste Mal.
Ich darf herzlich zum 2. Strong-IT Security-Roundtable mit anschließender Penthouse-Party einladen!
Datum: Fr. 24.05.2019 ab 14:30
Ort: SoHo2 Veranstaltungsraum OG4 (Grabenweg 68 – Innsbruck)
Parken: Inhouse Tiefgarage
Grobe Agenda:
14:30 Eintrudeln
15:00 Endpoint-Hardening: How to find the gap (David Winkler)
15:30 Angriffsvektoren im Active-Directory (Robert Rostek)
16:00 Malware-Engineering und AMSI-Bypass-Methoden (Daniel Feichter)
16:30 Coffee Break
17:00 Toolset Primer: Social Datamining mit Maltego (Martin Gratt)
17:15 Toolset Primer: Erkennung von DNS C2 Kanälen mittels Firewalls? (Dominik Hofreiter)
18:00 Buffet, Getränke, Party, DJ Roxxor
Anmeldungen (Anzahl Personen; Party ja/nein) bitte an office@strong-it.at
Limit: 40 Plätze – first come (register), first serve.
Strong-IT war gestern zu Gast beim „Kuratorium für sicheres Österreich“. Wir durften vor zahlreich erscheinendem und teils prominentem Publikum zum Thema „Passwort.Wahnsinn“ referieren – was ist eine digitale Identität, wie stehlen und missbrauchen Angreifer diese, und wie kann man sich bestmöglich schützen. Teil des Vortrags waren Live-Demos, wie zum Beispiel das Auslesen aller Credentials aus dem Passwortspeicher eines Webbrowsers, oder eine Webseite auf der Klartextpasswörter von Personen aus dem Publikum zu sehen waren.
Hier noch ein Foto der Vorbereitungen. Herzlichen Dank für die Einladung!
So, i was hunting this bug today, that popped up for quite a while now in our sccm logs.
The important piece of information is that our servers have no internet connection – we block all external traffic with a firewall. The SCCM server has a special ruleset to allow downloading of wsus updates. the ruleset consists of two parts. First, the firewall allows the „ms-update“ layer-7 protocol. Second, the http and https protocols are allowed, but only to specific microsoft update urls. The url list contains:
(and all *.xxxx variants)
These urls are no big secret and can be found by reading the documentation or googling forums, reddit, etc… Strangely enough, everything was working fine for many month, win 10 updates synced as well as server 2016 updates, and also office 365 updates were downloaded correctly and so on. But suddenly, some specific updates stopped syncing correctly:
Synchronizing update f1fe6a6b-f554-4ad0-8eb5-27ee707ea001 – Office 365 Client Update – Semi-annual Channel Version 1705 for x86 based Edition (Build 8201.2294)
ProcessFileManifest() failed to process O365 file manifest. Caught exception: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send…[snip]
Skipped update f1fe6a6b-f554-4ad0-8eb5-27ee707ea001 – Office 365 Client Update – Semi-annual Channel Version 1705 for x86 based Edition (Build 8201.2294) because it failed to sync.
Patchdownloader.log shows no information about the failed updates, only those that were successful. So it was impossible to determine what additional / new url the server tried to access. The problem is also reported in this reddit post, but the solutions did not apply to our case. So what next?
After enabling in-depth url tracking on a temporary rule on our firewall, we noticed this log entry:
Uhm….. config.office.com ?! what the…. thats something new. A quick google search revealed this: https://techcommunity.microsoft.com/t5/Deployment/Configuration-Manager-1806-integrates-config-office-com-for/td-p/221225. Alright. Nice that sccm now has this new „feature“. Not nice that this silently breaks automatic patching……
So the fix was rather easy: add config.office.com to the url set on the firewall, resync updates (disable o365 category, sync, enable it again, sync again). If you are also keeping your firewall rulesets tight like we do, then hopefully this post helps.
Happy patching!