Keylogger Data Stored in an ADS, (Tue, Jul 15th)

If many malware samples try to be "filess" (read: they try to reduce their filesystem footprint to the bare minimum), another technique remains interesting: Alternate Data Streams or "ADS"[1]. This NTFS feature allows files to contain multiple data streams, enabling hidden or additional metadata to be stored alongside the main file content without being visible in standard file listings. A common usage of ADS is the "Mark of the Web"[2] that helps to flag files as suspicious or not depending on their origin.

I found a simple Python keylogger that implements an ADS to store the captured keystrokes:

hidden_dir = os.path.join(os.environ['APPDATA'], 'Microsoft\\Windows\\Cache')
os.makedirs(hidden_dir, exist_ok=True)
log_host_file = os.path.join(hidden_dir, "syscache.dat")
log_file = log_host_file + ":logdata"

A second layer of protection is implemented to hide the file using SetFileAttributesW()[3] with the flag 0x02:

try:
    FILE_ATTRIBUTE_HIDDEN = 0x02
    ctypes.windll.kernel32.SetFileAttributesW(log_host_file, FILE_ATTRIBUTE_HIDDEN)
except Exception as e:
    print(f"Failed to hide host file: {e}")

The script is a classic keylogger but it also implements a clipboard monitor to capture all text content:

try:
    win32clipboard.OpenClipboard()
    if win32clipboard.IsClipboardFormatAvailable(win32clipboard.CF_TEXT):
        data = win32clipboard.GetClipboardData()
        win32clipboard.CloseClipboard()

The script (SHA256:9927159c39a0201e2fcd558c4716fc5cab7e1c6ab69a311f7a21cab3c5667980) has a low VT score (only 3/64) even if not obfuscated. The script does not have an exfiltration mechanism, therefore I presume that another one will take care of this!

How to detect if files have ADS on your file system? This can be achieve with a few lines of PowerShell:

Get-ChildItem -Recurse -Path C:\ | ForEach-Object {
    $streams = Get-Item $_.FullName -Stream * -ErrorAction SilentlyContinue
    if ($streams.Count -gt 1) { 
        $streams 
    }
}

Example:

PS C:\Users\REM> C:\Users\REM\Documents\ads_search.ps1

PSPath        : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop\PURCHASE_ORDER.exe::$DATA
PSParentPath  : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop
PSChildName   : PURCHASE_ORDER.exe::$DATA
PSDrive       : C
PSProvider    : Microsoft.PowerShell.Core\FileSystem
PSIsContainer : False
FileName      : C:\Users\REM\Desktop\PURCHASE_ORDER.exe
Stream        : :$DATA
Length        : 1044992

PSPath        : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop\PURCHASE_ORDER.exe:Zone.Identifier
PSParentPath  : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop
PSChildName   : PURCHASE_ORDER.exe:Zone.Identifier
PSDrive       : C
PSProvider    : Microsoft.PowerShell.Core\FileSystem
PSIsContainer : False
FileName      : C:\Users\REM\Desktop\PURCHASE_ORDER.exe
Stream        : Zone.Identifier
Length        : 608

[1] https://infosecwriteups.com/ntfs-filesystem-alternate-data-stream-ads-c0e4a2402563
[2] https://en.wikipedia.org/wiki/Mark_of_the_Web
[3] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileattributesw
 

Xavier Mertens (@xme)
Xameco
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/6Q4hX9e
via IFTTT

CitrixBleed 2 beckons sweeping alarm as exploits spread across the globe

Authorities and researchers are intensifying warnings about active exploitation and pervasive scanning of a critical vulnerability affecting multiple versions of Citrix NetScaler products.

There is now widespread agreement among security professionals that the critical vulnerability, CVE-2025-5777, which Citrix disclosed June 17, is serious and harkens back to a 2023 defect in the same products: “CitrixBleed,” or CVE-2023-4966. Naturally, threat hunters are scrambling to assess and stop the strikingly similar challenges summoned by exploits of the newest CVE. 

For some Citrix customers, the warnings are too late. Vulnerability scans confirm active exploits occurred within a week of disclosure, and attackers have been swarming, hunting for exposed instances of the impacted devices since exploit details were publicly released earlier this month. 

“This vulnerability in Citrix NetScaler ADC and Gateway systems, also referred to as CitrixBleed 2, poses a significant, unacceptable risk to the security of the federal civilian enterprise,” Chris Butera, acting executive assistant director for cybersecurity at the Cybersecurity and Infrastructure Security Agency, said in a statement. CISA added the exploit to its known exploited vulnerabilities catalog on July 10.

“As America’s cyber defense agency and the operational lead for federal civilian cybersecurity, CISA is taking urgent action by directing agencies to patch within 24 hours and we encourage all organizations to patch right away,” Butera added. The agency typically requires agencies to resolve “high risk” vulnerabilities within 30 days and “critical risk” vulnerabilities within 15 days.

The pre-authentication remote memory disclosure vulnerability, which has a CVSS score of 9.3, has been increasingly targeted for attacks globally. Imperva researchers on Friday said they’ve observed more than 11.5 million attack attempts targeting thousands of sites since the exploit was disclosed. 

“Attackers appear to be scanning extensively for exposed instances and attempting to exploit the memory-leak vulnerability to harvest sensitive data,” Imperva researchers said in a blog post.

Nearly 2 in 5 attack attempts have targeted sites in the financial services industry and 3 in 5 of those targeted sites are based in the United States, according to Imperva.

GreyNoise scans have observed 22 unique malicious IPs attempting to exploit CVE-2025-5777 thus far. The first malicious IP was observed June 23 and a spike of 11 unique malicious IPs was observed Friday. 

“I haven’t seen any attrition yet. This could be as bad or even worse than CitrixBleed,” Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, told CyberScoop. “The attack is very repeatable and those systems rarely have network monitoring. They also aren’t regularly updated, so patching them may be an issue.”

The number of Citrix customers already impacted remains unknown and victims have yet to come forward. 

“A lot of the attacks seem opportunistic, so there are likely multiple threat actors using the bug,” Childs said.

Citrix maintains there was no evidence of active exploitation when it disclosed the vulnerability. The vendor hasn’t shared much publicly in almost three weeks, other than an update in a June 26 blog post noting that CISA was aware of evidence of active exploitation. The company did not respond to a request for comment.

In the June blog post, Anil Shetty, senior vice president of engineering at NetScaler, disputed comparisons between CVE-2025-5777 and CVE-2023-4966. “While the vulnerabilities share some characteristics, Cloud Software Group has found no evidence to indicate that they are related,” Shetty wrote. Cloud Software Group is the parent company of Citrix.

Researchers are also leveling criticism at Citrix for the relative ease by which an attacker can compromise a vulnerable instance of Citrix NetScaler with just a few requests. 

‘“The term “CitrixBleed’ is used because the memory leak can be triggered repeatedly by sending the same payload, with each attempt leaking a new chunk of stack memory — effectively bleeding sensitive information,” Akamai Security Intelligence Group said in a blog post.

Akamai researchers described the root cause of the vulnerability as “an uninitialized login variable, combined with improper memory handling, lack of input validation and missing error handling in Citrix NetScaler’s authentication logic.”

Zach Edwards, an independent cybersecurity researcher, told CyberScoop that CVE-2025-5777 and CVE-2023-4966 are “extremely similar,” aside from subtle differences in the versions of NetScaler impacted.

“The fact that these pre-authentication vulnerabilities keep coming up, which can facilitate complete compromises, is disappointing to see,” Edwards said. “It’s unclear how these significant vulnerabilities keep making their way through development processes, but Citrix clients, especially in the government and enterprise sectors, should be demanding more and requiring additional public context about the steps Citrix takes to test its software prior to a release.”

The post CitrixBleed 2 beckons sweeping alarm as exploits spread across the globe appeared first on CyberScoop.

from CyberScoop https://ift.tt/PbNKLXf
via IFTTT

DShield Honeypot Log Volume Increase, (Mon, Jul 14th)

The volume of honeypot logs changes over time. Very rarely are honeypot logs quiet, meaning that there are no internet scans or malicious activity generating logs. Honeypots can see large increases in activity [1], but this has tended to be the exception, rather than the rule. Within the last few months, however, there has been a dramatic increase in honeypot log volumes and how often these high volumes are seen. This has not just been from my residential honeypot, which has historically seen higher log volumes, but from all of the honeypots that I run and archive logs from frequently. 

 


Figure 1: Log volumes for multiple honeypots over the last 13-14 months. Recent activity has drowned out earlier traffic volumes, making them appear nonexistent. 

 

To help demonstrate that other logs do exist, the high volume contributors were filtered out. Any source network (/24 in size) that contributed more than 1,000,000 logs in a day was removed.


Figure 2: Log volumes over time when filtering out sources that have contributed more than 1,000,000 logs in a day. 

 

The source of the log volume has been from the web honeypot logs.


Figure 3: Web honeypot log volumes have been the highest contributor for these outliers. 

 

More activity can be seen earlier in the year when large volume contributors are taken out. Even though this allows us to see more data prior to April of 2025, there is still an obvious increase in the last few months. 


Figure 4: Web honeypot logs for the last 13-14 months, factoring out sources that have contributed more than 1,000,000 logs in a single day. 

 

Previous high volume periods are also unable to be seen easily due to the recent higher log volume. 


Figure 5: Previous days considered to be anomalous in terms of high-volume traffic barely register in comparison to recent web honeypot logs.

 

It has not been uncommon to see web honeypot files greater than 1 GB for a day of activity in the last couple of months. In the last few weeks, multiple honeypots have generated logs over 20 GB for one day of activity and for multiple days. In one day, a honeypot generated nearly 58 GB of web honeypot logs, which beat a previous "record" of ~35 GB.


Figure 6: The volumes are increasing, but are also happening more often, demonstrated by a significant rise in the average size of locally stored web honeypot logs.

 

So where are these logs coming from and what are they looking for? Since many source IP addresses were seen coming from overlapping subnets, the data was summarized by subnet. The data highlights that some subnets are focused on a small number of unique URL paths.

Subnet Web Honeypot Hits Unique IP Count Unique URL Path Count Top IP Top URL Path
45.146.130.0/24 20078392935 6 55 %%ip:45.146.130.107%% /
179.60.146.0/24 15730010424 2 2 %%ip:179.60.146.100%% /__api__/v1/config/domains [2]
185.93.89.0/24 4976900543 6 134 %%ip:185.93.89.185%% /
204.152.199.0/24 4421115971 9 2 %%ip:204.152.199.8%% /
72.11.141.0/24 4241370914 13 2 %%ip:72.11.141.14%% /
96.47.225.0/24 3636730956 9 2 %%ip:96.47.225.5%% /
185.193.88.0/24 3610407610 4 4 %%ip:185.193.88.178%% /__api__/v1/config/domains
155.94.185.0/24 3165292268 9 2 %%ip:155.94.185.3%% /
149.56.205.0/24 2718351438 1 3 %%ip:149.56.205.13%% /
193.111.208.0/24 2517999488 1 3 %%ip:193.111.208.87%% /
193.29.13.0/24 2248677302 1 2 %%ip:193.29.13.44%% /
92.63.196.0/24 2204582018 5 4 %%ip:92.63.196.179%% /__api__/v1/config/domains
80.82.65.0/24 927668585 3 3 %%ip:80.82.65.127%% /
151.243.93.0/24 560421646 1 3 %%ip:151.243.93.62%% /
79.141.162.0/24 527387481 1 3 %%ip:79.141.162.39%% /
83.229.17.0/24 463243368 2 4 %%ip:83.229.17.112%% /
91.199.163.0/24 447956151 1 2 %%ip:91.199.163.102%% /__api__/v1/config/domains
141.98.80.0/24 174475074 22 3 %%ip:141.98.80.136%%
46.161.27.0/24 76298489 9 3 %%ip:46.161.27.97%% /
80.243.171.0/24 68840696 1 18152 %%ip:80.243.171.172%% /
171.22.28.0/24 60795298 2 2 %%ip:171.22.28.30%% /
45.227.255.0/24 39617032 7 4 %%ip:45.227.255.90%%
184.105.247.0/24 33156996 46 7 %%ip:184.105.247.252%% /
213.209.150.0/24 23439064 2 2 %%ip:213.209.150.239%% /
204.76.203.0/24 17219727 15 1127 %%ip:204.76.203.206%% /
198.7.119.0/24 14768235 2 5437 %%ip:198.7.119.14%% /index.php
77.90.153.0/24 13968760 2 144 %%ip:77.90.153.248%% /
185.218.84.0/24 12687799 13 4 %%ip:185.218.84.178%% /
65.49.20.0/24 11897736 61 6 %%ip:65.49.20.68%% /
74.82.47.0/24 9974952 61 6 %%ip:74.82.47.3%% /
184.105.139.0/24 8966536 60 7 %%ip:184.105.139.67%% /
111.170.18.0/24 8271554 1 1 %%ip:111.170.18.49%% api.ipapi.is:443
185.91.127.0/24 7976326 10 27 %%ip:185.91.127.66%% myip.wtf:443
216.218.206.0/24 6055214 61 6 %%ip:216.218.206.66%% /
98.82.141.0/24 4647608 1 6724 %%ip:98.82.141.184%%
51.222.26.0/24 4598477 2 7029 %%ip:51.222.26.42%%
23.234.91.0/24 4454070 1 1 %%ip:23.234.91.166%% /
5.183.209.0/24 3993952 1 6 %%ip:5.183.209.244%% /
37.19.221.0/24 3922037 4 1 %%ip:37.19.221.152%% /
149.50.103.0/24 3764760 1 1 %%ip:149.50.103.48%% /
154.81.156.0/24 3665899 10 10 %%ip:154.81.156.7%% /
207.167.67.0/24 3593126 7 6 %%ip:207.167.67.206%%
64.62.197.0/24 3456463 240 8 %%ip:64.62.197.92%% /
207.180.204.0/24 3291942 1 6911 %%ip:207.180.204.178%%
124.198.132.0/24 2937813 14 1 %%ip:124.198.132.155%% /api/sonicos/is-sslvpn-enabled
132.226.159.0/24 2878302 1 184 %%ip:132.226.159.101%%
84.247.172.0/24 2787287 4 6953 %%ip:84.247.172.209%% /index.php
193.41.206.0/24 2764461 11 3170 %%ip:193.41.206.24%% /.env
80.65.211.0/24 2463234 1 6767 %%ip:80.65.211.20%%
185.191.126.0/24 2379847 2 7 %%ip:185.191.126.248%% /
87.236.176.0/24 2333336 252 4 %%ip:87.236.176.117%% /
154.83.103.0/24 2276967 23 6369 %%ip:154.83.103.106%% /.git/HEAD
132.226.122.0/24 2145978 1 184 %%ip:132.226.122.74%%
179.43.168.0/24 2088416 2 74 %%ip:179.43.168.146%% /
191.252.194.0/24 1999452 1 6725 %%ip:191.252.194.180%%
65.49.1.0/24 1993183 232 8 %%ip:65.49.1.94%% /
13.41.162.0/24 1933149 1 6725 %%ip:13.41.162.60%%
185.177.72.0/24 1919963 17 3864 %%ip:185.177.72.111%% /.git/HEAD
179.43.161.0/24 1616473 2 1 %%ip:179.43.161.218%% /
193.26.115.0/24 1595736 9 15 %%ip:193.26.115.193%% /api/sonicos/is-sslvpn-enabled
84.201.151.0/24 1568962 1 1281 %%ip:84.201.151.18%% /index.php
64.62.156.0/24 1519319 219 8 %%ip:64.62.156.108%% /
75.119.147.0/24 1513333 1 6912 %%ip:75.119.147.56%%
139.144.52.0/24 1504276 1 569 %%ip:139.144.52.241%% /
79.124.58.0/24 1503070 1 9 %%ip:79.124.58.198%% /
31.220.89.0/24 1444043 1 6724 %%ip:31.220.89.104%%
157.245.174.0/24 1426128 1 53 %%ip:157.245.174.148%%
94.72.105.0/24 1420774 2 12531 %%ip:94.72.105.70%% /
78.153.140.0/24 1346725 16 1372 %%ip:78.153.140.179%% /.env
193.68.89.0/24 1332852 7 6 %%ip:193.68.89.51%% /
45.148.10.0/24 1328615 33 347 %%ip:45.148.10.235%% /cmd,/simZysh/register_main/setCookie
148.113.208.0/24 1308479 1 1 %%ip:148.113.208.45%% /
141.98.11.0/24 1298067 49 811 %%ip:141.98.11.128%% /
176.65.148.0/24 1217874 34 23 %%ip:176.65.148.243%% /
84.201.170.0/24 1194041 1 3070 %%ip:84.201.170.229%% /
84.201.181.0/24 1177504 2 1749 %%ip:84.201.181.85%% /
162.62.233.0/24 1176321 1 1280 %%ip:162.62.233.142%%
45.84.89.0/24 1106375 2 1 %%ip:45.84.89.2%% /
195.3.221.0/24 1063626 1 14 %%ip:195.3.221.137%% /
158.160.162.0/24 1016033 1 8095 %%ip:158.160.162.122%% /

Figure 7: Common URLs accessed by subnets, with overall subnet activity and the most active IP address for each subnet.

 

URL Path Total Hits
/ 38,052,002,400
/__api__/v1/config/domains [3] 33,198,670,474
/__api__/v1/logon 1,635,235,500
api.ipapi.is:443 8,270,636
myip.wtf:443 7,914,843

Figure 8: 5 Most common URL paths seen for active subnets. 

 

There is a lot more data to look into, but this activity may require additional action for anyone hosting a honeypot and retaining additional logs. For me, I'm working on archiving more local logs more frequently to save space. This may mean doing high compression zipping of web honeypot logs, potentially twice a day. It may be necessary to consider having over 20 GB of logs per day for multiple days. If log backups and cleanup happen once per week, this may mean storage of 140 GB of just web honeypot logs between backups. 

 

[1] https://isc.sans.edu/diary/Overflowing+Web+Honeypot+Logs/30416
[2] https://isc.sans.edu/diary/Web+Scanning+SonicWall+for+CVE202120016+Update/31952/
[3] https://isc.sans.edu/diary/31906
 


Jesse La Grew
Handler

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/Teq6bkd
via IFTTT

AWS Weekly Roundup: AWS Builder Center, Amazon Q, Oracle Database@AWS, and more (July 14, 2025)

Summer is well and truly here in the UK! I’m a bit of a summer grinch though so, unlike most people, I’m not crazy about “the glorious sun” scorching me when I’m out and about. On the upside, this provides the perfect excuse to retreat to the comfort of a well-ventilated room where I can focus on coding and curating the latest AWS releases to bring you the highlights.

I also managed to escape the heat for most of yesterday while recording an episode for the AWS Developers Podcast where the wonderful Sebastien Stormaq and Tiffany Souterre interviewed me about games development. If you haven’t discovered it yet, I highly recommend you give it a go as the episodes are full of interesting lessons and insights from not just AWS, but customers and community members who share their stories and expertise in a relaxed conversation.

Alright, ready to discover some of the new things we released last week? Here are the highlights.

AWS Builder Center
There is a new home for AWS builders and community members! AWS Builder Center is a new place where cloud builders can connect, share knowledge, and access resources to enhance their AWS journey. The platform enables users to join community programs, discover trending topics, access AWS Skill Builder courses, participate in technical challenges, and more, using a single Builder ID sign-in.

One the features that I’m personally most excited about is the Wishlist. You can now create wishes and tell AWS directly about ways to improve our products and services or share original ideas that you think could help you and your teams. You can also browse and upvote existing wishes to support any suggestions that you think should be prioritized. The AWS teams will keep an eye on this and if a wish has enough traction it may just be considered!

Read the news blog post for a quick tour through some of the most exciting features or head over to AWS Builder Center and start exploring!

AI
The world of AI keeps moving fast and changing our world, by providing new and exciting ways to do things and become more productive. Here are two releases from last week that caught my attention.

  • Amazon Q chat in the AWS Management Console can now query AWS service data – Amazon Q Developer expands its capabilities by enabling natural language queries of data stored across AWS services like S3, DynamoDB, and CloudWatch, directly from the AWS Console, Slack, Microsoft Teams, and AWS Console Mobile Application. This enhancement streamlines cloud management and troubleshooting by allowing users to access and analyze service data through conversational interfaces, with access controls managed through IAM permissions.
  • Amazon CloudWatch and Application Signals MCP servers for AI-assisted troubleshooting – AWS has released two new Model Context Protocol (MCP) servers – CloudWatch MCP and Application Signals MCP – that enable AI agents to leverage observability data for automated troubleshooting through conversational interfaces. These open-source servers allow AI assistants to analyze metrics, alarms, logs, traces, and service health data across AWS environments, streamlining incident response and root cause analysis without requiring developers to manually navigate multiple AWS consoles.

Oracle Database@AWS
It seems like yesterday when Andy Jassy announced our partnership with Oracle to create Oracle Database@AWS, a jointly offered service that runs Oracle databases on Exadata infrastructure directly within AWS data centers, providing a unified AWS-Oracle experience. Fast forward to last week and Oracle Database@AWS has reached a significant milestone with its general availability release. It is now available in US East (N. Virginia) and US West (Oregon) regions, with plans to expand to 20 additional regions globally.

In addition, VPC Lattice has added support for Oracle Database@AWS enabling seamless connectivity between applications in VPCs and on-premises environments to Oracle database networks. The integration simplifies network management and provides secure access from Oracle Database@AWS to AWS services like Amazon S3 and Amazon Redshift, without requiring complex networking setup.

So if you’re looking to migrate your Oracle database workloads, now is a great time to explore Oracle Database@AWS as it offers a compelling path forward with minimal modifications required.

Additional highlights
Here are some other releases that I think many people will be happy about.

  • AWS Config now supports 12 new resource types – AWS Config has expanded its monitoring capabilities with support for 12 new resource types across services including BackupGateway, CloudFront, EntityResolution, Bedrock, and more. These additions are automatically tracked if you have enabled recording for all resource types, enhancing your ability to discover, assess, and audit AWS resources.
  • Amazon SageMaker Studio now supports remote connections from Visual Studio Code – Amazon SageMaker Studio now supports remote connections from Visual Studio Code, allowing developers to use their familiar VS Code setup while leveraging SageMaker’s scalable compute resources for AI development.
  • AWS Network Firewall: Native AWS Transit Gateway support in all regions – AWS Network Firewall now offers native integration with AWS Transit Gateway across all supported regions, enabling direct attachment and simplified traffic inspection between VPCs and on-premises networks. This integration eliminates the need for managing dedicated VPC subnets and route tables while providing multi-AZ redundancy for improved security and reliability.

Upcoming AWS Events
AWS Summit New York – this is definitely one to watch…literally! Registrations are closed due to capacity but you can tune in to watch live all the announcements and launches! No spoilers, but, trust me, there are a quite a few exciting things in store, so make sure to check it out.

AWS Gen AI LoftsAWS Gen AI Lofts are multi-day events offering hands-on workshops, expert guidance, and networking opportunities for developers and business leaders looking to explore or advance their generative AI journey. These events are hosted across multiple global locations including San Francisco, Berlin, Dubai, Dublin, Bengaluru, Manchester, Paris, and Tel Aviv, providing accessible opportunities to accelerate your generative AI adoption.

And that’s it for this week! Come back next Monday for more highlights and keep your AWS knowledge up to date as we cover the latest releases.

Matheus Guimaraes | @codingmatheus

from AWS News Blog https://ift.tt/t9FyocU
via IFTTT

New White House cyber executive order pushes rules as code

In an era characterized by escalating cybersecurity threats, rapidly evolving technological landscapes, and heightened regulatory demands, organizations face significant pressure to modernize their Governance, Risk, and Compliance (GRC) practices. The federal government is also pivoting toward automation, with Policy-as-Code (PaC) becoming a foundational element in modern cybersecurity governance and compliance.

A critical driver accelerating this urgency is a recent executive order that explicitly underscores robust cybersecurity frameworks, continuous monitoring, and adaptive compliance strategies. In response, organizations must move toward adopting innovative solutions such as Policy-as-Code methodologies.

Aligning with the cyber EO

In June, the White House issued an executive order that directs the National Institute of Standards and Technology, the Cybersecurity and Infrastructure Security Agency, and the Office of Management and Budget to launch a pilot within one year that expresses federal cyber policy in a machine‑readable format. The same section instructs the Federal Acquisition Regulation Council to revise procurement rules so that by January 2027, agencies may buy only consumer IoT products whose Cyber Trust Mark can be parsed automatically. 

This isn’t just a technical experiment: It’s a blueprint for the future of cyber governance. This is a decisive endorsement of automation-based compliance and signals a governmentwide expectation that policy implementation must be verifiable, scalable, and code-driven.

These deadlines extend beyond federal departments. Any company that sells software, cloud services, or connected devices to the public sector will soon need to prove that its security controls are written and enforced through machine‑readable rules. The fastest and most reliable way to supply that proof is Policy-as-Code. Teams that move early will gain an advantage when the new rules shape purchasing decisions. Teams that wait risk a backlog of manual controls and a shrinking share of government business.

What is Policy-as-Code?

Policy-as-Code refers to the practice of translating governance, risk management, and compliance policies into machine-readable formats by leveraging automation, and creating a more structured, dynamic, and scalable compliance environment. Policy-as-Code removes ambiguity from interpretation and puts security policies on equal footing with infrastructure and application logic. The result is a proactive compliance governance that scales as fast as today’s threats. 

The Risk Management Framework (RMF) has long provided structured guidelines for organizations to categorize, select, implement, assess, authorize, and continuously monitor their information systems. However, traditional RMF processes often rely heavily on manual efforts, making them less responsive and increasingly prone to errors in today’s fast-paced digital environment. 

As of today:

  • Release velocity has accelerated: Development teams merge code many times each day; manual assessment packages cannot keep pace.
  • Architectural complexity has grown: Hybrid clouds, containers, edge devices, and software‑as‑a‑service platforms create connections too dense for spreadsheet mapping.
  • Regulatory concurrency has intensified: Programs must show conformance with FISMA, FedRAMP, CMMC, the Secure Software Development Framework, multiple state privacy laws, and sector‑specific rules at the same time.

Policy-as-Code resolves these gaps because rules run continuously, update quickly, and leave a clear evidence trail. 

Strategic benefits of implementing Policy-as-Code

Organizations adopting Policy-as-Code experience several transformative benefits, positioning themselves advantageously within a highly competitive regulatory environment:

  • Risk reduction: Automated enforcement minimizes risks associated with human error, improving compliance accuracy and reducing vulnerabilities.
  • Audit efficiency: Immutable logs replace screenshots, shared drives, and labor‑intensive walk‑throughs.
  • Operational efficiency: Automating policy enforcement streamlines processes, significantly reducing the administrative burden and enabling teams to focus on strategic tasks rather than routine compliance checks.
  • Regulatory agility: When NIST updates a control catalog, teams change one file and push the update across every environment with a pull request.
  • Enhanced security posture: Real-time monitoring capabilities bolster an organization’s security posture, swiftly identifying and addressing potential threats or breaches.
  • Cost savings: By reducing the manual effort needed for compliance monitoring and enforcement, Policy-as-Code can lead to considerable cost reductions over time.
  • Greater resilience: Codified governance reduces ambiguity and enhances organizational readiness under stress.
Making it Work: practical steps for effective implementation

To effectively adopt Policy-as-Code and maximize its benefits, organizations should consider the following structured approach:

  • Comprehensive policy mapping and evaluation: Begin by evaluating every policy, regulation and policy applicable to your organization, map all the frameworks (e.g. NIST SP 800-53, ISO/IEC 27002 etc.) applicable to your organization, and assign a unique identifier to each of the mapped control. This mapping forms the foundation for robust automation.
  • Select an open declarative machine-readable language: Choose a well‑supported machine-readable format — like NIST’s Open Security Controls Assessment Language (OSCAL) or Open Policy Agent (OPA) — that integrates with existing infrastructure‑as‑code (IaC), container orchestration, and pipeline tools.
  • Convert prose to machine‑readable schemas: Translate Word and PDF controls into structured formats such as OSCAL.
  • Integration into development pipelines: Evaluate and deploy specialized automation platforms capable of integrating seamlessly into existing DevSecOps workflows and lifecycle. These platforms should offer real-time compliance verification, automated remediation capabilities, and ensure continuous validation of compliance at every stage of the software development process, from initial coding through deployment and operation.
  • Ongoing monitoring and continuous improvement: Implement robust tools for continuous compliance monitoring. Regularly review and update policy logic to accommodate evolving regulatory landscapes and cybersecurity threats.
  • Automate evidence collection: Connect cloud APIs, container scanners, and endpoint telemetry to a central repository so evidence accrues automatically.
  • Training and capacity building: Invest in targeted training programs to equip your teams with the necessary technical and conceptual understanding of Policy-as-Code methodologies and Git workflows, and teach developer teams regulatory vocabulary.
  • Cultural alignment and leadership support: Actively cultivate a culture that values compliance automation and proactive risk management. Secure buy-in and sustained support from senior leadership to ensure smooth adoption and integration.
  • Pilot and iterate: Begin with a high-priority control (e.g., encryption at rest) and run a focused pilot. Measure its effectiveness, gather stakeholder feedback, and iterate. Success here builds momentum.
  • Inform and measure impact: Codified controls should feed into your broader risk dashboards and compliance reporting mechanisms, track policy coverage, mean time to remediation, audit hours saved, and defects prevented. Share results with executive stakeholders.
The road ahead

The future of cybersecurity governance clearly points toward increased automation, dynamic regulatory adaptation, and highly responsive compliance frameworks. Policy-as-Code is not merely a temporary trend but a fundamental shift in how organizations approach GRC. Soon, federal contracts may require delivery of not only human-readable SSPs but also machine-verifiable compliance packages. Audits may involve running scripts instead of reviewing PDFs. And AI-powered governance engines will cross-check deployments against codified policies in real time.

The EO’s emphasis on rules-as-code is just the beginning. The EO also sets timelines for managing AI vulnerabilities and adopting post‑quantum cryptography. Agencies must publish an AI vulnerability dataset by Nov. 1 and must transition to quantum‑resistant encryption by 2030. 

The clock is ticking. Agencies must pilot rules as code by June 2026, and suppliers must attach machine-readable security labels by January 2027. Organizations that translate policy into executable pipelines now will close vulnerabilities faster, cut assessment costs, and enter bid rooms as trusted partners. Those that wait will face manual backlogs, increased expenses, and shrinking market share once the grace period ends. Policy-as-Code is no longer experimental, but an operational and compliance imperative that will distinguish tomorrow’s security-ready organizations from everyone else.

The future of cyber and AI governance won’t be documented; it will be deployed!

Ibrahim Waziri Jr. is a principal security product manager in Microsoft’s Cybersecurity, Cloud, AI & Trust Engineering Team, a cybersecurity fellow at New America, and an adjunct professor of cybersecurity at Marymount University.

The post New White House cyber executive order pushes rules as code appeared first on CyberScoop.

from CyberScoop https://ift.tt/6Wg4Bad
via IFTTT

Experimental Suspicious Domain Feed, (Sun, Jul 13th)

We have had a "newly registered domain" feed for a few years. This feed pulls data from ICANN's centralized zone data service (https://czds.icann.org) and TLS certificate transparency logs.

The ICANN CZDS is a good start, but it only offers data from top-level domains collaborating with ICANN. Missing are in particular country-level domains. Country-level zone files can be hard to come by, so we use TLS certificate transparency logs as a "cheap" alternative. Pretty much all domain registrars will, by default, create a "parked" website, and with that, they will make a certificate. Even if they do not, any halfway self-respecting phishing site will use TLS and register a certificate with a public certificate authority at one point. The TLS certificate transparency logs also help capture older domains.

Each day, we capture around 250,000 new domains using this system. But of course, we want to know which domains are used for malicious purposes. However, as the sample below shows, there are a lot of "odd" domain names.

domainname
jgcinversiones.com
h20manager.net
1sbrfreebet.com
stability.now
mdskj.top
internationalone19.com
clistrict196.org
agenteinsider.com
720airpano.com
dhofp.tax
bos228btts.lol
japansocialmarketing.org
mummyandimedia.com
1dyzfd.buzz
oollm.shop
snapztrailk.store
perumice.com
nrnmy.sbs
commaexperts.com
softfragments.com

So I searched for some commonly used criteria to identify "bad" domain names, and found these:

  • A domain name is very short or very long
  • The entropy of the domain name (is it just random characters?)
  • Does it contain a lot of numbers or hyphens?
  • Is it an international domain name, and if so, is it valid? Does it mix different scripts (=languages)?
  • Does it contain keywords like "bank" or "login" that are often used with phishing sites, or brand names like "Apple" or "Google"?

We have now added a score to each domain name that can be used to rank them based on these criteria. You can find a daily report here, and the score was added to our "recentdomain" API feed. This is experimental, and the exact algorithm we use for the score will change over time.

We used to have an "old" supicous domain feed that was mostly based on correlating a few third party feeds, but over time these feeds went away or became commercial and we could no longer use them.

Feedback is very welcome.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/xkzRYWm
via IFTTT

Securing Data in the AI Era

The 2025 Data Risk Report: Enterprises face potentially serious data loss risks from AI-fueled tools. Adopting a unified, AI-driven approach to data security can help.
As businesses increasingly rely on cloud-driven platforms and AI-powered tools to accelerate digital transformation, the stakes for safeguarding sensitive enterprise data have reached unprecedented levels. The Zscaler ThreatLabz

from The Hacker News https://ift.tt/nClGStx
via IFTTT