[HN Gopher] Exploiting signed bootloaders to circumvent UEFI Sec...
___________________________________________________________________
Exploiting signed bootloaders to circumvent UEFI Secure Boot
Author : todsacerdoti
Score : 82 points
Date : 2026-02-08 14:40 UTC (8 hours ago)
(HTM) web link (habr.com)
(TXT) w3m dump (habr.com)
| ronsor wrote:
| (2019)
|
| The biggest weakness of secure boot was always third-party
| vendors shipping "insecure" bootloaders. It's a lot of work to
| verify signatures for every bit of data that gets loaded,
| especially on the PC platform.
| jeroenhd wrote:
| Thre original secure boot design would have had insecure
| bootloaders get blacklisted the moment abuse could be detected.
|
| Microsoft then made that system entirely useless by signing
| code that could be used to load unsigned code, like
| demonstrated here.
|
| They then also refused to blacklist their own broken bootloader
| to save sysadmins the time (who would need to deploy new
| recovery images and boot media containing the fixed
| bootloader). That vulnerable bootloader is particularly bad
| because it can be used to have the TPM unlock itself and give
| up the Bitlocker key, which the Linux loaders shouldn'tbe
| capable of even if they apply the bypass mentioned in the
| article.
|
| In a world where Microsoft cared about secure boot, they would
| blacklist the vulnerable Linux loaders as well as their own old
| bootloaders. Why Microsoft? Because they signed the files in
| the first place, only they can rescind the signatures. In that
| world, Linux users would call for Bill Gates' head for securing
| their security feature and sysadmins would be out for Steve
| Ballmer's blood for breaking their complex custom recovery
| system that nobody dares touch.
|
| Now we'll be stuck in the worst of both worlds.
| gruez wrote:
| >They then also refused to blacklist their own broken
| bootloader to save sysadmins the time (who would need to
| deploy new recovery images and boot media containing the
| fixed bootloader).
|
| Source? The OP suggests they expect it to be blacklisted
|
| >I assume that Kaspersky bootloader signature certificate
| will not live long, and it will be added to global UEFI
| certificate revocation list, which will be installed on
| computers running Windows 10 via Windows Update
|
| If you search around you'll also find that microsoft does
| publish secure boot revocations, contrary to what you claim.
|
| https://github.com/fwupd/dbx-firmware
| jeroenhd wrote:
| They blacklist some bootloaders, but it takes them forever.
| CVE-2023-24932 (from May 2023) had a fix available a year
| later (June 2024), had the update broadly made available
| through standard updates in 2025 (2 years later) and
| doesn't automatically install it today.
|
| You might think the 2025 update will solve the problem,
| but:
|
| > Before following these steps for applying the
| mitigations, install the Windows monthly servicing update
| released on July 8, 2025, or a later update on supported
| Windows devices. This update includes mitigations for
| CVE-2023-24932 but they are not enabled by default. All
| Windows devices should complete this step regardless of
| your plan to enable the mitigations.
|
| The current status for the update
| (https://support.microsoft.com/en-us/topic/how-to-manage-
| the-...) says:
|
| > The Enforcement Phase will not begin before January 2026,
| and we will give at least six months of advance warning in
| this article before this phase begins. When updates are
| released for the Enforcement Phase, they will include the
| following:
|
| Basically, unless your company and sysadmin have enforced
| this fix (i.e. you're a home user), Microsoft hasn't
| revoked their keys.
|
| Then there's CVE-2024-38058, a similar attack. Microsoft
| tried to roll out a fix, but that broke compatibility, and
| the fix was then rolled back. Again, that problem can be
| fixed with the solution for the previous CVE, but that is
| still not deployed by default.
|
| https://neodyme.io/en/blog/bitlocker_screwed_without_a_scre
| w... describes the TPM2 attack in detail as well as
| mitigations and solutions much better than I can.
| rcxdude wrote:
| A better design would not involve a small default-trusted set
| of keys in the first place. If the signers were diverse and
| on equal footing, with users choosing who to trust, a single
| bad bootloader being signed would not compromise nearly the
| whole ecosystem.
| Lucasoato wrote:
| I feel like this isn't the best moment to call Bill Gates. Or
| maybe yes, maybe he'll open source Windows at this point, who
| knows!
| mjg59 wrote:
| Third party? Black Lotus was the first case we saw actually
| targeting individuals, and that was a vulnerability in the
| Windows bootloader.
| Bratmon wrote:
| It's really funny to me that Microsoft's attempt to finally stamp
| out desktop Linux once and for all failed because one of
| Microsoft's antivirus vendor partners couldn't write secure
| software to save their lives.
|
| The continued Linux desktop solely relies on antivirus vendors
| writing crappy insecure software. So we'll be fine forever.
| bri3d wrote:
| > It's really funny to me that Microsoft's attempt to finally
| stamp out desktop Linux once and for all failed
|
| This conspiracy was never true and never happened. First off,
| note that the first version of the thing in the article you're
| commenting on relied on a Fedora shim loader which Microsoft
| signed. Second off, note that almost all modern motherboards
| let you enroll your own UEFI keys and do not rely on
| exclusively the Microsoft keys.
|
| The only place this is was becoming an issue for Linux was
| early Secure Boot implementations where the vendor was too lazy
| to allow key enrollment, and that era has generally passed.
| yjftsjthsd-h wrote:
| I don't think it deserves quite that easy a dismissal; MS
| _did_ lock down early UEFI+ARM devices and prohibit user-
| controlled keys (see the Windows RT devices as an example).
| Given their history of playing dirty, it 's perfectly
| reasonable that people assumed this to be another play at
| undermining Linux, even if things didn't end up going that
| way.
| bri3d wrote:
| By 2019, when the parent article was written, I don't think
| that was a good read on the situation. By 2026, when the
| parent comment was written, I really don't think it's a
| good read on the situation.
| pbhjpbhj wrote:
| It's hard to believe when MS use secure boot to prevent Linux
| being able to boot. Twice now on my dual boot system a
| Windows update has prevented Linux being bootable. If it
| weren't for MS's history one might consider it the accident
| of a ridiculously inept company.
|
| Even just the lies around required hw updates is enough not
| to trust them.
|
| SecureBoot looks like a system designed to make it hard to
| change OS, it has been used by MS for that, MS have a history
| of user-antagonist actions.
|
| You say the conspiracy was never true, I'm going to need some
| serious proof.
| NekkoDroid wrote:
| > SecureBoot looks like a system designed to make it hard
| to change OS
|
| To be fair SecureBoot is in a way just that: it is intended
| to only boot binaries that are signed with a key that has
| been enrolled into the UEFI. The main issue is like almost
| always how those keys are managed.
| invokestatic wrote:
| No, this is not true at all. Microsoft _requires_ their system
| vendors (Dell, HP, etc) to allow users to enroll their own
| Secure Boot keys through their "Designed for Windows"
| certification.
|
| Further, many distributions are already compatible with Secure
| Boot and work out of the box. Whether or not giving Microsoft
| the UEFI root of trust was a good idea is questionable, but
| what they DO have is a long, established history of supporting
| Linux secure boot. They sign a UEFI shim that allows
| distributions to sign their kernels with their own,
| distribution-controlled keys in a way that just works on 99% of
| PCs.
| mhitza wrote:
| Is it possible to un-enroll the Microsoft certificates, and
| just trust the efi shim?
| bri3d wrote:
| With almost all modern motherboard firmware you can enter
| Setup mode and use KeyTool to configure the trust store
| however you want, starting from enrolling a user PK
| (Platform Key) upwards.
|
| It's generally a lot more secure to avoid the use of any
| shims (since they leave you vulnerable to what happened in
| this article) and just build a UEFI Kernel Image and sign
| that.
|
| Some systems need third party firmware to reach the OS, and
| this can get a bit more complicated since those modules
| need to load with the new user keys, but overall what you
| are asking is generally possible.
| mistrial9 wrote:
| > just build a UEFI Kernel Image and sign that.
|
| examples and documentation welcome
| bri3d wrote:
| https://wiki.archlinux.org/title/Unified_kernel_image#uki
| fy_...
| trelane wrote:
| https://wiki.gentoo.org/wiki/Secure_Boot
| NekkoDroid wrote:
| > Is it possible to un-enroll the Microslop certificates
|
| Technically yes, with a massive fucking asterisk: Some
| option-ROM are signed with the MS certs and if your
| Motherboard doesn't support not loading those (whether
| needed or not) you will not be able to sometimes even POST.
|
| https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
| TacticalCoder wrote:
| > It's really funny to me that Microsoft's attempt to finally
| stamp out desktop Linux once and for all
|
| SecureBoot exists on servers too. And that's the domain of
| Linux, not Windows.
|
| Microsoft should never have had so much influence in SecureBoot
| but there's no way they're getting rid of Linux on servers.
| Microsoft is mostly irrelevant there.
|
| > The continued Linux desktop solely relies on antivirus
| vendors writing crappy insecure software. So we'll be fine
| forever.
|
| That's also a weird take. It's antivirus vendors who are going
| to be fine forever: they rely on Microsoft to write crappy
| insecure software. And that is a given.
| ThrowawayB7 wrote:
| If you Google around, you'll find that about 1/3 of server
| operating systems broken down by revenue (not install count)
| is Windows Server. That's billions of dollars.
| bri3d wrote:
| > Most motherboards include only Microsoft keys as trusted
|
| Is this really true, in 2019 when this was written or today? I
| haven't seen a motherboard that didn't let me enroll my own keys
| in a really long time. Laptops are a different story but even
| there, it's been awhile.
|
| > Microsoft forbid to sign software licensed under GPLv3 because
| of tivoization restriction license rule
|
| Ah yes, GPLv3 is now Microsoft's fault?
| NekkoDroid wrote:
| > Is this really true, in 2019 when this was written or today?
|
| This is true in the sense that they only ship with MS' keys as
| trusted, but all MoBos (including laptops) I had allow
| enrolling your own. Some might handle not having MS' keys
| better (or at all) than others, but it should in theory be
| possible to remove them, whether it will boot after is a
| different question (see option-ROM [1])
|
| [1]: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
| TacticalCoder wrote:
| >Ah yes, GPLv3 is now Microsoft's fault?
|
| You are missing the point. It's the fault of those who pushed
| SecureBoot down our throats (and don't get me wrong: I use
| SecureBoot) to have decided that Microsoft had both a free-pass
| to have its certs by default in every UEFI out there but no
| other certs.
|
| So users either have to understand how to enroll their own
| certs _or_ to use a shim signed by... Microsoft.
|
| Let's not forget that we're talking about the company
| responsible for Windows 11 here.
| bri3d wrote:
| > You are missing the point
|
| Of the GPLv3 sentence? No, it's dishonest rhetorically. Of
| the piece? Also I don't think so, exploiting the shims is a
| fun way to prove that Secure Boot is silly but we already
| knew that, and by 2019 claiming that "most" systems only
| allowed Microsoft keys is just flat out dishonest as well.
|
| > It's the fault of those who pushed SecureBoot down our
| throats (and don't get me wrong: I use SecureBoot) to have
| decided that Microsoft had both a free-pass to have its certs
| by default in every UEFI out there but no other certs.
|
| I really don't get this argument in general; Microsoft certs
| are enrolled by default as a combination of: a matter of
| convenience for majority users who are going to use Microsoft
| OSes, the unfortunate design of Option ROM signature
| checking, and the desire to get a Windows logo on the
| packaging and Microsoft OEM discounts.
|
| There's no Secure Boot or UEFI related reason that boards
| can't come in Setup Mode with no PK, and most industrial
| boards do indeed come this way, since they don't need Option
| ROMs and customers don't want a Microsoft logo.
|
| > So users either have to understand how to enroll their own
| certs or to use a shim signed by... Microsoft.
|
| This seems like the best outcome for end-user computers which
| will have Windows installed to me? Users get a computer that
| checks that the OS it came with is valid (well, tries to, but
| that's a different can of worms), and still have the option
| to do whatever they want with it if they so desire. They can
| choose the Microsoft signed shim for convenient dual-booting,
| or erase the platform keys and own their system end to end if
| they wish.
|
| > Let's not forget that we're talking about the company
| responsible for Windows 11 here.
|
| I've never really understood these arguments, and it's even
| weirder to bring Windows 11 into it. Is the thing we're
| railing against here Ballmer-Borg Microsoft? Shitty Product
| Management Kills Products Microsoft? AI Infested Microsoft?
| The Venn diagram of overlap between 1990s Microsoft (genesis
| of UEFI), 2012 Microsoft (Secure Boot introduction), and 2025
| Microsoft (Windows 11) seems likely to be... quite small.
| mjevans wrote:
| Empowering the 'User' (hardware owner) should have always been
| the focus.
|
| From that mindset what makes sense are hardware vendors including
| a cache of trusted third party root certificates from known other
| vendors. Today this would include Microsoft, the same said
| hardware vendor, probably various respected Linux
| organizations/groups (Offhand, Linux Foundation, ArchLinux,
| Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
|
| Crucially the end user should then be ASKED which to enable. None
| should be enrolled out of the box. They might also be enabled
| only for specific things. E.G. HW vendor could be enabled only
| for new system firmware signatures (load using the existing
| software) rather than generic UEFI boot targets. The user should
| also be able to enroll their own CA certs as well; multiple of
| them. Useful for Organization, Division Unit, and system local
| signatures.
|
| It would also, really, be nice if UEFI mandated a uniform access
| API (maybe it does) for local blobs stored in non mass-storage
| space. This would be a great place to stash things like UEFI
| drivers for accessing additional types of hardware drivers, OS
| boot bits + small related files, etc. I would have said 1GB of
| storage would be more than sufficient for this - however
| Microsoft has proven that assumption incorrect. Still it'd be
| nice to have a standard place and a feature that says the system
| ships with this much reliable secondary storage included (or
| maybe 1-2 micro-SD card slots, etc).
| mistrial9 wrote:
| > Crucially the end user should then be ASKED which to enable
|
| except, on the other side of the "strange fellows" are people
| who rose to executive authority by ruthless focus on control of
| every aspect of their business, and profit including excluding
| others who did actual work. There is zero point zero chance of
| any argument that relies on "should" to work IMHO
|
| this is a political situation by definition -- vastly different
| yet connected members of society and economics, seeking the
| rule of law to enable stable markets. hint- some of the same
| decision makers are the ones that pay to put spy code in your
| large new TV or appliances.
| NekkoDroid wrote:
| > From that mindset what makes sense are hardware vendors
| including a cache of trusted third party root certificates from
| known other vendors. Today this would include Microslop, the
| same said hardware vendor, probably various respected Linux
| organizations/groups (Offhand, Linux Foundation, ArchLinux,
| Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
|
| IMO systems should be shipped in "Setup Mode" by default with
| no keys preinstalled. On first boot which ever OS you decide to
| install should be able to enroll its keys.
|
| This way it is entirely agnostic of any cherrypicked list of
| "trust me" vendors. You'd still have most of the benefits of
| easy secure boot enrolling for those that don't know what it
| even is/how to do it while also allowing easy choosing of other
| OSes (at least on initial first boot).
|
| The main problem currently is option-ROM which has a tendency
| to cause the system to not even POST if secure boot is enabled
| without MS keys. Recently bricked a MoBo this way and even
| though it has 2 BIOS I can't actively choose which one to boot,
| it just has some "trust me, I know when" logic that chooses...
| well guess how well that is working for me...). The Asrock
| board I replaced it with though has an option for what it
| should do with such option-ROM when secure boot is active
| (don't run, always run, run if signed, ...)
|
| > The user should also be able to enroll their own CA certs as
| well; multiple of them. Useful for Organization, Division Unit,
| and system local signatures.
|
| Isn't this already the status quo??
|
| > It would also, really, be nice if UEFI mandated a uniform
| access API (maybe it does) for local blobs stored in non mass-
| storage space. [...]
|
| I think UEFI is already complex enough and most of this can in
| a way already somewhat be handled by the EFI System Partition,
| e.g. systemd-boot can tell the UEFI to load (file system)
| drivers off of it (https://wiki.archlinux.org/title/Systemd-
| boot#Supported_file...), I don't know if UEFI technically
| supports other types of drivers to be loaded.
| bitwize wrote:
| > IMO systems should be shipped in "Setup Mode" by default
| with no keys preinstalled. On first boot which ever OS you
| decide to install should be able to enroll its keys.
|
| Nobody wants to "install" an operating system. Computers
| should come with an OS preinstalled and ready to run.
| Everything else is a dead letter in terms of the marketplace.
| NekkoDroid wrote:
| I was talking about the same "install" that is already done
| (pre-installed on the drive that is first booted).
|
| Enrolling certs into the UEFI isn't something that needs to
| be done manually when "Setup Mode" is enabled, the
| bootloader can automatically enroll them.
|
| This already is a thing with the exception of the ship in
| "Setup Mode" part. Though some motherboard UEFI
| implementations are shit (as to be expected) and shit their
| pants when this happens.
|
| See last paragraph in this section as example: https://www.
| freedesktop.org/software/systemd/man/latest/syst...
| bri3d wrote:
| What would be the point of this change? It erodes
| security in some moderately meaningful way (even easier
| to supply chain new computers by swapping the boot disk)
| to add what amounts to either a nag screen or nothing, in
| exchange for some ideological purity about Microsoft
| certificates?
| NekkoDroid wrote:
| It really doesn't. UEFI are still not by default locked
| behind a password (can't be locked since you couldn't
| change settings in the UEFI if that were the case), so
| anyone that has access to change a drive can also disable
| secure boot or enroll their own keys if they want to do
| an actual supply chain attack.
|
| If your threat model is "has access to the system before
| first boot" you are fucked on anything that isn't locked
| down to only the manufacturer.
| bri3d wrote:
| What if my threat model is "compromised the disk imaging
| / disk supply chain?" This is a plausible and real threat
| model, and represents a moderate erosion, like I said.
|
| UEFI Secure Boot is also just not a meaningful
| countermeasure to anyone with even a moderate paranoia
| level anyway, so it's all just goofing around at this
| point from a security standpoint. All of these "add more
| nag screens for freedom" measures like the grandparent
| post and yours don't really seem useful to me, though.
| lacunary wrote:
| I have always enjoyed the experience of installing my
| favorite hobbyist teletype operating system. I think the
| last time I used a preinstalled on a personal machine was
| windows 3.1 on a 486.
| josephg wrote:
| > IMO systems should be shipped in "Setup Mode" by default
| with no keys preinstalled. On first boot which ever OS you
| decide to install should be able to enroll its keys.
|
| I don't think this works with the security model of secure
| boot. The secure boot rom is supposed to sit above the OS -
| as in, it's more privileged than the OS. A compromise in the
| OS can't lead to a compromise in secure boot. (And if it
| could, why even bother with secure boot in the first place?)
|
| If the OS could enrol whatever keys it wants, then malware
| could enrol its own malware keys and completely take over the
| system like that. And if that's possible then secure boot
| provides no value.
| NekkoDroid wrote:
| The enrolling of the certs happen before the bootloader
| calls `ExitBootServices()` (I think that is what the
| function was called). Up until then the bootloader still
| has elevated priviledges and can modify certain UEFI stuff
| it can't after, including enrolling certs.
|
| systemd-boot can do that if you force it to (only does it
| by default on VMs cuz expectedly UEFI implementations in
| the wild are kinda shit)[1, 2]
|
| [1]: https://www.freedesktop.org/software/systemd/man/lates
| t/syst...
|
| [2]: https://www.freedesktop.org/software/systemd/man/lates
| t/load...
| mjg59 wrote:
| No, there's nothing special about the spec secure boot
| variables as far as boot services goes - you can modify
| those in runtime as well. We use boot service variables
| to protect the MOK key in Shim, but that's outside what
| the spec defines as secure boot.
| gruez wrote:
| >IMO systems should be shipped in "Setup Mode" by default
| with no keys preinstalled. On first boot which ever OS you
| decide to install should be able to enroll its keys.
|
| Sounds like browserchoice.eu but even more pointless. For the
| normies who don't care about what keys they want installed,
| it doesn't make a difference. For people who want to switch
| to linux, it also doesn't make a difference because unless
| they're setting up their computer for the first time, because
| the windows key would already be installed. The only thing it
| does is make setting up a new computer marginally easier for
| one specific case (ie. you want to install a non-windows
| operating system AND you don't want to dualboot), and ticks
| off a box for being "vendor agnostic" or whatever.
| bitwize wrote:
| This is what you get when a programmer designs a system.
|
| The end user wants to be able to just pick up a computer from
| Best Buy and have it work, out of the box.
|
| Microsoft can't even conceptualize why you would want to run
| anything but the Windows that came with the machine. If the
| expected Windows kernel and files aren't there, or have been
| altered, that is evidence of malicious tampering--malware that
| must be stopped. (I'm deliberately steelmanning their
| perspective here.)
|
| Streaming services want a secure content path. Game vendors
| want protection against cheating. In order to comply with
| local/regional/national laws, web sites need you to verify your
| age, and they need to know your computer is not lying (remote
| attestation). Nobody wants to be hacked.
|
| The incentives for everyone else besides techies align against
| techies getting to run arbitrary code on their devices. The
| Secure Boot system is working precisely as designed.
| dist-epoch wrote:
| > Game vendors want protection against cheating
|
| Gamers, gamers want anti-cheats. Vendors couldn't care less.
| rcxdude wrote:
| Gamers want no cheaters, vendors want to be seen to be
| trying in the cheapest way that has credibility.
| josefx wrote:
| It is 2026, people still use cheat software on public
| servers. It works about as well as DRM.
|
| > Vendors couldn't care less.
|
| There are more than enough games that are designed around
| microtransactions that use grind and gambling mechanics to
| encourage spending. Throw bots and cheats at that and the
| entire thing breaks down.
| charcircuit wrote:
| The security story of the PC platform is such a mess due to
| fragmentation. I have way more trust in Apple's security here.
| varispeed wrote:
| Security through obscurity is not a great idea. This is what
| Apple's current approach is. For instance if your iPhone is
| infected with malware, there is no anti-virus software that can
| find it, because Apple doesn't let software to have such deep
| access that is needed for scanning.
| charcircuit wrote:
| It's not security by obscurity. It's security by minimizing
| the attack service by being extremely picky about what you
| sign. When it is paramount that the code you sign is correct
| you can't go signing a ton of different projects from people
| who may not even care about security as much as you do.
|
| >For instance if your iPhone is infected with malware
|
| Then restarting it will remove it. So far Apple has had a
| perfect record with this unlike Android.
| varispeed wrote:
| > Then restarting it will remove it. So far Apple has had a
| perfect record with this unlike Android.
|
| Not things like Pegasus.
|
| It does not minimise attack surface, but minimise ways
| _you_ can ensure there is nothing on the phone that
| shouldn't be there.
| ronsor wrote:
| > Apple doesn't let software to have such deep access that is
| needed for scanning
|
| Normalizing "security" software running in the background to
| "scan" things has proven a social and technical disaster.
| Users think it's normal to have such activity (and receive
| random "virus alerts"), leading to over two decades of social
| engineering scams, fraud, and malware-delivery. On top of
| that, "security" software has a habit of creating its own
| security holes and problems. Look at game anti-cheats (one
| was just on the front page the other day), the CrowdStrike
| incident, etc.
|
| OS vendors should simply deliver a secure OS. That isn't
| easy, but it's still easier and more reliable than shipping
| third-party "security" software after the fact.
| varispeed wrote:
| The issue isn't "normalising pop-up virus scanners" or
| letting random vendors hook the kernel. It's verifiability.
| On Apple platforms, the security model is explicitly "trust
| us bro". You cannot independently inspect the system at the
| level required to detect certain classes of compromise,
| because Apple forbids it.
|
| A platform where compromise is, by design, undetectable to
| the owner is not "more secure", it's merely less
| observable. That's security through opacity, not security
| through design.
|
| Yes, third-party security software has a bad history. So
| does third-party everything. That doesn't magically make a
| closed system safer. It just moves all trust to a single
| vendor, removes independent validation, and ensures that
| when something slips through, only the platform owner gets
| to decide whether it exists.
|
| "The OS vendor should deliver a secure OS" is an
| aspiration, not an argument. No OS is bug-free. Defence in
| depth means independent mechanisms of inspection, not just
| a promise that the walls are high enough.
|
| Apple's model works well for reducing mass-market malware
| and user error. It does not work for high-assurance trust,
| because you cannot verify state. If you can't audit, you
| can't prove clean. You can only assume.
|
| That may be a perfectly acceptable trade-off. But let's not
| pretend it's the same thing as stronger security. It's a
| different philosophy, and it comes with real blind spots -
| which to some people make Apple devices a non-starter.
___________________________________________________________________
(page generated 2026-02-08 23:00 UTC)