Puts me in mind of this scathing report from CISA on how a state-sponsored group broke into Microsoft and then into the State Department and a bunch of other agencies. Reads like a heist movie.
What I found most incredible about the story is that it wasn't Microsoft who found the intrusion. It was some sysadmin at State who saw that some mail logs did not look right and investigated.
Yesterday ProPublica and ArsTechnica published a takedown of Azure: "Federal cyber experts called Microsoft’s cloud a “pile of shit,” approved it anyway" ...
Every security engineer I know working at Azure is on the verge of self-harm because of the current situation, or is the dumbest IC I've ever met and somebody I think should have never become a security engineer. Sample size ~12.
IIRC, (& I don't remember if I reported it), but Azure's audit logs don't reflect reality when you delete a client secret from the UI, either.
If I remember the issue right, we lost a client secret (it just vanished!) and I went to the audit logs to see who dun it. According to the logs, I had done it. And yet, I also knew that I had not done it.
I eventually reconstructed the bug to an old page load. I had the page loaded when there were just secrets "A" & "B". When I then clicked the delete icon for "B", Azure deleted secrets "B" and "C" … which had been added since the page load. Essentially, the UI said "delete this row" but the API was "set the set of secrets to {A}". The audit log then logged the API "correctly" in the sense of, yes, my credentials did execute that API call, I suppose, but utterly incorrectly in the sense of any reasonable real-world view as to what I had done.
Thankfully we got it sorted, but it sort of shook my faith in Azure's logs in particular, and a little bit of audit logs in general. You have to make sure you've actually audited what the human did. Or, conversely, if you're trying to reason with audit logs, … you'd best understand how they were generated.
I don't think I would ever accept audit logs in court, if I were on a jury. Audit logs being hot lies is within reasonable doubt.
Puts me in mind of this scathing report from CISA on how a state-sponsored group broke into Microsoft and then into the State Department and a bunch of other agencies. Reads like a heist movie.
https://www.cisa.gov/sites/default/files/2024-03/CSRB%20Revi...
What I found most incredible about the story is that it wasn't Microsoft who found the intrusion. It was some sysadmin at State who saw that some mail logs did not look right and investigated.
Don't worry CISA and any other involved regulator were gutted by DOGE.
Yesterday ProPublica and ArsTechnica published a takedown of Azure: "Federal cyber experts called Microsoft’s cloud a “pile of shit,” approved it anyway" ...
https://arstechnica.com/information-technology/2026/03/feder...
In which one expert called the documentation provided "a pile of shit", which propublica took the liberty of extending to Azure itself
And they weren’t wrong
Bloomberg and CNBC don't seem to have reported about this, maybe someone with contacts could make them aware?
Ars just republished it under license
Every security engineer I know working at Azure is on the verge of self-harm because of the current situation, or is the dumbest IC I've ever met and somebody I think should have never become a security engineer. Sample size ~12.
Bypassing logging feels relatively unimportant compared to some of the recent EntraID vulns we’ve seen
It takes a village of exploits to raise a successful and undetected attack.
IIRC, (& I don't remember if I reported it), but Azure's audit logs don't reflect reality when you delete a client secret from the UI, either.
If I remember the issue right, we lost a client secret (it just vanished!) and I went to the audit logs to see who dun it. According to the logs, I had done it. And yet, I also knew that I had not done it.
I eventually reconstructed the bug to an old page load. I had the page loaded when there were just secrets "A" & "B". When I then clicked the delete icon for "B", Azure deleted secrets "B" and "C" … which had been added since the page load. Essentially, the UI said "delete this row" but the API was "set the set of secrets to {A}". The audit log then logged the API "correctly" in the sense of, yes, my credentials did execute that API call, I suppose, but utterly incorrectly in the sense of any reasonable real-world view as to what I had done.
Thankfully we got it sorted, but it sort of shook my faith in Azure's logs in particular, and a little bit of audit logs in general. You have to make sure you've actually audited what the human did. Or, conversely, if you're trying to reason with audit logs, … you'd best understand how they were generated.
I don't think I would ever accept audit logs in court, if I were on a jury. Audit logs being hot lies is within reasonable doubt.