Podcast Detail

SANS Stormcast Wednesday, September 16th, 2026: MacOS 27 Traffic; Cisco 0-Day; Protecting Active Directory and API Tokens

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/10096.mp3

previous
Podcast Logo
MacOS 27 Traffic; Cisco 0-Day; Protecting Active Directory and API Tokens
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Wednesday, September 16th,
 2026 edition of the SANS Internet Storm Center's
 Stormcast. My name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Undergraduate Certificate Program in Applied
 Cyber Security. Well, it's a little addition to yesterday's
 Apple update. I did today something I haven't done in a
 while and that's just record the traffic that you should
 expect from a system as you're booting it up for the first
 time until you log in. Well, in this particular case, no
 big surprises. Actually, what surprised me a little bit was
 how similar it was to the last few versions of macOS. Really,
 very little has changed, if anything, really has changed.
 Makes passive operating fingerprinting maybe a little
 bit more difficult for me as a packet geek. Now, in the post,
 I focused on some of the features that may be less
 known, but again, nothing really new. First of all, the
 way IPv6 duplicate address discovery is working here,
 there is sort of an ICMPv6 option, a nonce, a little
 random byte sequence is being added here to prevent some of
 the spoofing and denial of service attacks. DNS traffic,
 nothing really too exciting again, but what we see here
 is, for example, attempting to discover secure DNS servers
 like DNS over HTTPS. Also, one very important host name that
 you have to be a little bit careful with as an Apple user,
 albert.apple.com. That particular host is used to
 verify the association of the device with an Apple ID
 account. So basically, device lock, device activation is
 being done via this account, so don't block it. Also, you
 can't do TLS interception on it because it does TLS
 certificate pinning a couple other host names like this. As
 far as TCP goes, it still uses a fairly conservative Windows
 scale and then just four connections overall. Again, a
 TLS connection to this albert host, the online certificate
 status protocol to verify the certificate for this
 particular host and then two TLS connections to essentially
 set up the push messaging and such in macOS. What surprises
 me actually, the one thing that still hasn't changed is
 when Apple originally switched from Intel to its own ARM
 processors, they did not change the user agent string
 in Safari. Actually, other browsers like Google Chrome
 also haven't changed it. They still say Intel. Apparently,
 that's sort of to provide compatibility issues with some
 websites. And yep, it still says Intel. Now, I think we're
 about sort of six years later. Well, if you're using Cisco's
 secure email gateway, there is a SQL injection vulnerability
 that Cisco patched yesterday. And this vulnerability is
 already being exploited to make things more interesting.
 Everything of course runs as root. And with this SQL
 injection vulnerability, an attacker is able to gain
 arbitrary code execution on your secure email gateway by
 just sending you an email that as Cisco states includes SQL
 code. Now, they also do post some indicators of compromise
 here how you can check your logs for any essentially the
 SQL snippets that you may find there. And they give you a
 couple examples how to do that and what particular sort of
 SQL code to look for. Be a little bit flexible there as
 you're doing the search. That's likely based on the
 current available exploit that they have seen being used in
 the wild. Wouldn't be surprised if there are a
 couple other things that you can do with this vulnerability
 that may not necessarily get caught by the simple crap
 patterns that they have included in the advisory. So
 yeah, get it patched because this does not require access
 to any control plane or such. It just requires sending an
 email, which of course, the secure email gateway has to
 process. So we have another one of those sort of
 authoritative documents that some of the cybersecurity
 agencies worldwide sometimes get together and come up with.
 I'm linking to the CISA version here. But overall, I
 think the other agencies will have their own copy of this
 document. This time, it's about detecting and mitigating
 Active Directory compromises. Yes, Active Directory, I hear
 it's still a thing. In particular, of course, for
 lateral movement, it sort of tends to be one of the
 favorite tools attackers are using. And this document,
 again, very authoritative, very exhaustive, is going over
 all the various misconfigurations that are
 being exploited by these attackers. I think it's about
 70 pages. It talks about the vulnerabilities, how to
 prevent them, and then also how to detect a compromise,
 which I think is always a real helpful section here to tell
 you what to look for in your logs to see if you have been
 compromised. Because after all, it can get quite tedious
 and difficult to actually enforce all of the right
 configuration of options in Active Directory. Talking
 about government issued recommendations, we also got a
 new interagency communications, as they call
 it from NIST, that talks about how to protect tokens and
 assertions from forgery, theft, and misuse. What this
 really about is, well, this big problem that we are having
 with sort of a proving identity, and particular sort
 of the non-human identities like API access and such, how
 you're going to manage all of the access tokens and such
 that are involved in that very detailed document. Sometimes
 these NIST documents are a little bit too wordy for my
 taste, but I think lots of good points being made and a
 good checklist you can build from this. Technically, these
 documents are really only applying to the US federal
 government, but a lot of other private sector companies,
 governments and other countries and such often use
 them as a guideline to sort of develop their own rules how to
 deal with various security issues. And I think this is
 sort of a real good sort of starting point to build your
 own policies around these ID tokens and assertions. Well,
 this is it for today. So, thanks for listening. Thanks
 for liking. Thanks for recommending and subscribing
 and whatever else this podcast and talk to you again
 tomorrow. Bye.