Kevin Beaumont

Didn't atmfd.dll get removed from Windows 10? I cannae remember.

The documentation is in line now and up to date:

Seeing some minor variation of BlueKeep attack behaviour (maybe attackers updated Metasploit finally), I'm seeing some stable'ish exploitation of Windows 7 this week however they're failing to run commands properly. Example commands; Additional IoCs. Application event 1000, spawning Powershell.exe: This event spawns from C:\Windows\system32\UI0Detect.exe and UI0Detect.exe 224 (224 is the parameter). spoolsv.exe crash: They check the device has more than 3.5gb of RAM, and is 64 bit, then try running a payload. Network IOC 78.46.124.69 port 10095

So I saw some exploitation of this in wild yesterday, looks like: Obviously the POST statements aren't there. Triggers code execution like this:

There’s a public write up for triggering this vulnerability now (not RCE). https://www.coresecurity.com/blog/dejablue-vulnerabilities-windows-7-windows-10-cve-2019-1181-and-cve-2019-1182 @MalwareTech

Perfect - thank you very much. So it is delayed now, and they're add opt out registry values for later. (If anybody is confused, Microsoft have multiple pieces of conflicting info on this - e.g. this one is still online: )

I haven't noticed any performance issues here. This website supports HTTP/2 and TLS 1.3.

In March this year, Microsoft plan to change LDAP (an authentication system) behaviour so you are required to make connections which is signed and basically secure. If you have systems which authenticate with Active Directory in an insecure way, they will break post update. More info here: https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023 This is a big change which may have production impacts, i.e. systems may break. How to identify systems which will break Go to your domain controllers and look for Event ID 2887: Product: Windows Operating System ID: 2887 Source: Microsoft-Windows-ActiveDirectory_DomainService Message: During the previous 24 hour period, some clients attempted to perform LDAP binds that were either: (1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or (2) A LDAP simple bind that was performed on a cleartext (non-SSL/TLS-encrypted) connection If you see this error, you need to take action as something will break. You can manually enable LDAP interface event logging, and afterwards Event ID 2889 will be logged in same location with the IP addresses of clients using insecure LDAP. On each DC: # Enable Simple LDAP Bind Logging Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2 This will get you the IP address of systems using insecure LDAP.. the next issue is to get them to... not do that. Over to you!

The boilerplate description "A vulnerability has been identified in Citrix Application Delivery Controller (ADC) formerly known as NetScaler ADC and Citrix Gateway formerly known as NetScaler Gateway that, if exploited, could allow an unauthenticated attacker to perform arbitrary code execution." What it means in practice Unauthenticated remote code execution on internet connected Citrix Gateway devices = bad. Are attackers actually exploiting this vulnerability? Yes, at scale, against targeted and untargeted assets. Impact Lame stuff like coin miners, but also devices getting backdoored, and people trying to use this to deploy ransomware inside Windows orgs behind the Citrix boxes. Vendor advisory and patches Here: https://support.citrix.com/article/CTX267027 Checking if your device has already been exploited Check out this tool, which is getting frequent updates: https://github.com/fireeye/ioc-scanner-CVE-2019-19781/tree/v1.2 Scale of the issue Somewhere in the region of ~100k devices were exploitable with this back in December. After have a huge awareness campaign via all sorts of orgs, this one is about ~10k unpatched devices at present. Those orgs are still in serious danger of exploitation. If you patched late You want to run the FireEye tool linked above to look for exploitation, as attackers may have backdoored your device. I just applied the mitigations You should also apply the patch, as it hardens the setup - just the mitigations alone present some issues.

I think as usual with Chrome stuff, as no code is disclosed nobody will know the deets.

Cheers. It looks like you need to have a pretty specific config to end up vulnerable to this.

Moving this topic public as the issue has made the media: https://news.sky.com/story/job-applicants-worried-as-hundreds-of-thousands-of-cvs-exposed-online-11836935

For a home Mac I wouldn’t bother.

That probably isn’t the use cases for HIBP, eg they don’t provide passwords.

Why do you think that?

I did a PoC with it at Crabbers back in 2016, but didn't reach the pentesting phase I'm afraid. I aborted out of it for cost reasons more than anything, and at the time the product functionality wasn't very broad (I bet it has improved a lot since). With Windows 10 nowadays it has lots of exploit protection built in, e.g. at current jobbing we have all the different exploit prevention technology turned on with Group Policy in Windows 10 pilot:

I haven't seen anything in my honeypots, just the usual RDP bruteforce stuff.

There's some more background on how a group used this used to hack Twitter and claim bug bounty: https://blog.orange.tw/2019/09/attacking-ssl-vpn-part-3-golden-pulse-secure-rce-chain.html

For some reason the vendor is lying press about the scale of the issue, saying a majority of customers have patched. Interesting response plan.

Some logs you can retrieve with this remotely: https://host/dana-na/../dana/html5acc/guacamole/../../../../../../data/runtime/logs/log.admin.vc0?/dana/html5acc/guacamole/ https://host/dana-na/../dana/html5acc/guacamole/../../../../../../data/runtime/logs/log.access.vc0?/dana/html5acc/guacamole/ As an attacker you can use these to figure out to some degree if the box has been tampered with already. Note that to have a hope of figuring out exactly what attackers tampered with, you need to manually (it is disabled by default) enable "Unauthenticated Web Requests" logging under System -> Logs/Monitoring in the Pulse Secure admin centre. As a result of this many orgs compromised before they installed the patch will not realise if attackers have created backdoors, and they may still be compromised. I recommend turning on logging, and looking at the admin logs - it won't catch everything (because HTTP requests aren't logged) but you might find other signs of tampering. Shoutout to Alyssa Herrera who continues to figure out this vulnerability.

For info - seen no scanning for this in the wild.

An anonymous researcher has pointed out you can remotely retrieve Active Directory usernames and passwords with this vulnerability - the passwords are encrypted, but always with the same passphrase ("NEOTERIS-FORM-CONFIRMATION"). So, essentially, not encrypted. Other hardcoded encryption keys are PSECURE-ADMINPWD-KEY, JUNIPER-ADMINPWD-KEY and others.