The protection I switched off to make CI pass

On the morning of 15 October an email landed from Google about a data export I hadn't asked for, and in roughly the time it takes to read a subject line I'd decided my eldest son's PC was compromised heavily and needed writing off.

It wasn't. The PC I should have been worrying about was his little brother's, and I found that out in the afternoon, about five minutes after I'd switched off a good half of what was standing between it and the malware.

The morning I wrote off the wrong PC

Some context first. My CI runs on the family's computers these days. The cloud runners went in September on cost, so the GitLab runners (the machines that pick up a pipeline's jobs and run them) now borrow my youngest's gaming PC while he's at school, and my eldest's while he's at work. My eldest's has a decent GPU in it too, and with his blessing I'd been borrowing that for some inference testing on go/chat-vllm.

So when the email came, I didn't hang about. The session looking after his machine locked it down and told the rest of the estate to distrust anything claiming to come from it. I changed my Google password before anyone had found a cause.

Ten minutes in, the penny dropped, and what I typed to the session was "I just realised what it was! it was edge importing settings from google". To borrow capacity on his machine I'd set up a user profile of my own, and Edge on a brand new profile very helpfully offers to pull your settings in from Google. Google, equally helpfully, emails you about it. Nothing had been compromised except my composure, and a Google password I'd changed for no reason at all.

My eldest shrugged when he heard. His PC was fine and he knew it was fine (he's been through an infection before, years ago, and he's a lot more savvy for it). The paranoia was all mine.

Sending the bouncer home

That afternoon was spent on the other PC, my youngest's, which had just been given the same runner hardening as his brother's. The runner had been running as Windows' all-powerful system account, with folder permissions loose enough that any user could read its registration token, so it moved to a hidden account with no admin rights and the folders got locked down. Very responsible. Then I pointed a Windows test job for go/mcp at it, and it fell over inside a minute:

An Application Control policy has blocked this file.

That's Smart App Control talking. If you've not met it (I'd barely met it myself, having run Linux as my main OS since 1997 and only touched Windows or a Mac when there was no other choice), it's a Windows 11 feature that acts like a bouncer on the door. Each program gets checked as it starts: is it signed, and does Microsoft's cloud reputation service know it? No ID and no reputation, and you're not getting in. That's lovely for a games PC and a real problem for Go, since go test compiles a brand new, unsigned binary for each package it tests, on each run. They all turn up at the door with no ID.

My first call, relayed through the session that runs the estate, was to keep SAC on and add an allow rule for just the runner's build folders. The PC's own session went and checked the logs, came back and said that wouldn't work. SAC itself was the blocker, and SAC doesn't take extra allow rules. It laid out the options, recommended keeping SAC on and pausing that runner, and pointed out (as had the estate session, a few minutes earlier) that switching SAC off was a one-way trip. It could only come back with a Windows reset.

Confession time... I didn't really read that part. I read "the runner works straight away", told it to turn Smart App Control off and re-run the job, and two minutes later the job was green!

Who he'd been turning away

Feeling pleased with myself, I asked the same session for a quick report-only sweep of my youngest's installed programs for adware, the sort of junk that piles up on any teenager's PC. A minute and a half later the first thing it reported back was that two scheduled tasks looked like malware hiding behind signed programs, "and Smart App Control was blocking them until I turned it off."

It was worse than that, once it had finished looking.

• A fake copy of a real app, sitting in his user folder. The program itself was the genuine signed article, wrapped around a malicious script that ran whenever he logged in, and that class of script exists to lift saved browser passwords and game and chat logins. It had probably been running since the summer.
• Two hidden scheduled tasks, each launching a properly signed program from a system folder with a planted DLL sitting beside it. That's DLL side-loading (worth a search if it's new to you): Windows loads the DLL it finds next to the program, the program is legitimate, and the code that actually runs is not.

This is where the bouncer gets complicated, as he'd only been doing half the job. The side-loading kit had been bounced off the door for months. The password stealer had sailed straight past him. It turned up inside a signed app with perfectly good ID, and a bouncer checking IDs can't do much about that. Defender only flagged it once the sweep went looking.

How it got there in the first place, I've no idea. He's had a lot of freedom with that PC since it arrived at Christmas, and my suspicion is that it got on there the way it gets onto most teenage lads' machines: something downloaded that promised a cheat for a game and brought some friends along with it. He received the news with the incredulity of someone denying all knowledge while silently admitting guilt... a technique I can respect, as a parent.

He wouldn't come back

The clean-up itself was fairly mechanical. An offline Defender scan, a full scan, and all the folders, tasks and installers belonging to the infection removed, and backups of it all kept until the end. Then I wanted my bouncer back.

Straight after the sweep, the session had flipped SAC back "on" in the registry, and Windows duly reported it as on and enforcing. It also let a fresh unsigned test program run straight through with nothing logged, before and after a reboot. The session's own word for it was "a label". Its suggestion was that I go to the PC and use the real switch in Windows Security, turning it off and back on again if it already said on.

So up the stairs I went. I switched it off. It would not switch back on, and what I sent back from his room was "I switched it off, now it wont let me switch it back on".

To its credit the session owned that one straight away: switching it off and on had been its idea, and the "on" I'd turned off had never been protecting anything. When I asked whether this was a limitation or some strange security feature, it explained the logic, and I think the logic is sound. SAC only checks programs as they start. It doesn't go looking for what's already installed. So if you could turn it off, install whatever you like, and turn it back on again, it would happily say "On" while something already settled in carried on running inside a hijacked signed program. Better to insist on a clean slate than give you a false sense of safety.

That was the rule for a long time. Except it's no longer the rule, or isn't meant to be. Microsoft's own page on what Smart App Control is now says recent updates let you switch it back on without a reinstall, and the press dates that to the April 2026 cumulative update. My youngest's PC was well past that. The session had even said as much before I went upstairs, which is why it thought the switch was worth a try.

So the warning I skipped was out of date, and on that PC it came true anyway. Maybe the registry fiddling left SAC in a state the switch couldn't climb out of. Maybe it was one of the cases Microsoft still excludes, like a PC with optional diagnostic data switched off (I don't think it was, but I wouldn't swear to it). Maybe the change simply hadn't reached that machine yet. I can't tell you, and now I never will...

Flattening it anyway

Getting the bouncer back was only part of it, though. A password stealer had been running on that machine since the summer, and with my history on Windows I wasn't going to trust it again until it had been flattened and rebuilt from nothing, just in case something insidious had been missed.

The session found what was worth keeping (about 165 MB of game saves and his bookmarks, everything else already in his OneDrive), zipped it up and put it in my OneDrive. It took the runner offline for good, and recommended a cloud download over a local reinstall so nothing from the old install got reused. It also warned me, quite reasonably, that its own notes about both PCs lived on that disk and would go with the wipe. Its transcript survived, as it happens, since I'd been driving the whole thing from the Mac downstairs.

The last thing I typed before the reset was "reset starting now, see you on the other side".

And then the passwords. Everything used on the old install went: Steam and the other gaming logins, his Microsoft and Google accounts, Snapchat, the whole lot. It was not a fun afternoon, sitting my son down to change them all, and I even had to change a few of my own, Google included. That made two resets on one account in one day, the morning's in a panic and the afternoon's for real, which is a special kind of fun. All very promptly, too... a stealer that's been running since the summer has had plenty of time to post what it found.

A bouncer on a trial shift

The PC came back two days later, and it came back different.

I'm liberal by nature. I'd rather both boys had admin rights on their own PCs, and they did until that week. But once you've been burned you take measures to make sure it doesn't happen again, so my youngest, who's just turned 16, is now a standard user. He's accepted that what he did caused a fair bit of consternation and let malware onto my home network (thankfully kept to his PC), and with my runners borrowing that machine on school days, I have to be able to vouch for the network. He hasn't complained once since, which probably tells you all you need to know about how that conversation went.

Smart App Control is back as well, in its evaluation mode for now: a bouncer on a trial shift, watching the door to decide whether he can stay. Memory integrity is on, the DNS filters out known malware domains, and Defender has the same tighter settings as his brother's PC, which had its own hardening pass that evening and its first-ever full scan (clean, of course). The runner work mostly moved somewhere SAC has no say over, a Linux container runner inside its own WSL2 distro, under its own account and capped at 12 GB and four cores. Go test binaries are Linux binaries in there, so as far as I can tell the bouncer at the Windows door never has to look at them.

Would I borrow my kids' PCs for CI again? I still am, every week. Each machine has a session attached to it that keeps it patched and tidy and switches the runners on and off when I need them, and my eldest was quite pleased that his came out of all this with its storage rearranged and a bit quicker for it. Best of all, I can look after both PCs without setting foot in either bedroom, and if you've ever met a teenage boy's bedroom you'll know that's the one door I'm happy to leave to someone else.

Originally published at phpboyscout.uk on 15 November 2026.