SANS Stormcast Tuesday, October 21st, 2025: Syscall() Obfuscation; AWS down; Beijing Time Attack

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/9664.mp3

previous

Syscall() Obfuscation; AWS down; Beijing Time Attack

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Tuesday, October 21st, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ulrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in Cyber
 Defense Operations. In diaries today we have Xavier talk
 about Python malware. Well, that's of course Xavier's
 thing. And this time Xavier ran into interesting Python
 malware that uses syscall. Syscall, of course, can be
 used to call arbitrary system functions. In this particular
 case it calls a function that will create a file handle in
 memory allowing for the malware itself to write then
 into memory, creating fileless malware. Now the malware
 itself is not really that remarkable as Xavier points
 out. It appears to be more of a proof of concept. It
 implements sort of some pseudo ransomware in the sense that
 it encrypts files with a one byte XOR key. So something
 that would be rather easy to brute force and then to
 decrypt. Which probably could of course then after they sort
 of got that fileless part working right be replaced with
 a more sophisticated encryption feature. This
 particular malware is somewhat recognized by various scanners
 according to VirusTotal but still not a great sort of
 detection rate here even though that call to syscall
 should be somewhat suspicious the way it's being used here.
 And of course the big news today was another outage at
 AWS apparently affecting the US East 1 region which usually
 tends to be one of those crucial regions if it fails.
 Well many other things fail as well. There are a number of
 different sites and services that were affected by this
 outage and if you had problems going to any number of
 different websites or using services and the like you
 probably ran into some issues today. Sans.org was also
 affected by this outage. At this point Amazon states on
 their service status page that they're sort of back to
 normal. I want to emphasize here a little bit the sort of
 part because they're still apparently throttling any new
 creations of systems and such and workloads to lambda and
 the like. So this still means that even though Amazon is
 running they're not running at full capacity and of course
 they figure out which services they shed and as a result many
 of their customers still aren't able to sort of operate
 their sites at full capacity. Now I've sort of seen this in
 particular the Sans.org website sort of go off and on
 again all afternoon today and as a result like I said you
 may have seen a maintenance message there the isc site isc
 .sans.edu is not running on Amazon so it happened to
 respond. This is really one of those common things that we
 have where we do have these bottlenecks that a lot of
 traffic goes through. Amazon's US East One is one of them. Of
 course no Cloudflare being a similar one. If one of these
 services down it really affects a large percentage of
 websites services being hosted via these particular
 resources. As a user there isn't really much you can do
 as a service provider using these services. Of course you
 always have to think about redundancy. It's not easy.
 It's not cheap to create redundancy and that's really
 what it comes down to sort of a business decision whether or
 not it's worth it to you to maybe sort of you know cover
 that. I'm not sure what it is. It appears to be sort of once
 a year or so where we have these major outages. Another
 item that created a lot of news headlines today was
 allegations by China that the US in particular they alleged
 the NSA did breach the systems responsible for maintaining
 the Beijing standard time. In the US of course there's also
 a similar standard time service operated by NIST and
 the US Naval Observatory. I want to stay a little bit away
 from the politics here and whether or not it happened or
 what exactly happened. The write-up of the breach is
 certainly interesting and something that you should look
 at because it illustrates one of these sort of more complex
 and persistent breaches and what techniques are being used
 there is certainly something that you sort of should read
 up on. But I want to focus here on the real reason why I
 decided to cover this and that's NTP is sort of one of
 my favorite protocols and you know time standards in general
 because I find they're often a little bit sort of an
 overlooked Achilles heel of network security. A lot of
 network security protocols whether it's Kerberos or many
 authentication protocols are relying on NTP and on accurate
 time synchronization Now there are a couple other standards
 as PTP sort of a more local network protocol that's often
 used for a time synchronization. Typically
 time synchronization actually happens in UTC and not in a
 specific time zone I'm not sure Beijing not having
 daylight savings time and also only having one time zone
 across China For them it may make more sense to use
 something like Beijing time as their internal standard
 instead of UTC But what it really means is that you must
 control your time standard and there are really two Things
 that you need to worry about Most of all you need to worry
 about having a consistent internal standard so that all
 of your internal clocks are in sync That's usually best done
 by having one or two internal time servers that all of your
 systems synchronize to I've sometimes played DNS tricks
 because so many systems by default use like you know time
 .apple.com or microsoft.com or the pool.ntp.org NTP pool for
 time synchronization and it can be difficult to get them
 all configured to use the correct internal time server
 So just DNS tricks can sometimes direct them to your
 internal time server There are options to digitally sign and
 encrypt these time signals That's certainly something to
 consider The second part is synchronizing your internal
 standard with an external standard And that's where you
 kind of need to look at first of all diversity Use several
 standard clocks that you're synchronizing with Look at who
 you're synchronizing with The pool.ntp.org has been reliable
 in the past but Anybody can sign up for it now most NTP
 servers all I know for the most part are able to reject
 certain clocks that are out of sync and That's certainly
 something then to consider. I've did some measurements
 about in the past and I probably Should publish
 something about this again when I get around to it The
 other thing of course the other option you have is GPS
 And that usually works really well and it's not really that
 terribly expensive to implement But in always
 whenever that external standard fails You then rely
 on the internal clock Being reasonably accurate and that's
 you know where The very cheapest clock may not
 necessarily be what you want to use And depending on the
 size your organization Spend a little bit more money on a
 decent standard clock that then maintains the time In
 case external references fail or a drift too far and that's
 again usually a configuration item For NTP servers where you
 can reject external clocks not just because they're out of
 sync with other external clocks But also because they
 would adjust your internal clock by a too much of a step
 certainly something to think about and To look at the
 architecture of your NTP distribution in your network
 Well, and visit for today, so thanks for listening. Thanks
 for liking thanks for recommending this podcast and
 talk to you again tomorrow Bye