The Civil Infrastructure Platform
(CIP) first launched in that form in April 2016, so it has a
tenth-anniversary celebration in its near future. At the 2025 Open
Source Summit Japan, Yoshitake Kobayashi talked about the goals of this
project and where it is headed in the future. Supporting a Linux system
for even one year is a challenging task; maintaining that support for a
decade or more is rather more so, and a changing regulatory environment
complicates the task further.
The modern enterprise doesn’t stand still. New domains are registered, acquisitions bring inherited infrastructure, cloud workloads spin up and down daily, and somewhere in the middle of it all, your visible footprint on the internet external attack surface keeps expanding.
For CISOs, this constant motion makes one CTEM step particularly difficult: discovery. You can’t validate what you can’t see and manual inventory updates can’t keep up with the pace of digital change.
That’s why Rapid7 is introducing dynamic EASM discovery for Surface Command, a new capability that automatically identifies and tracks every part of your external attack surface. By continuously ingesting known domain and IP information from your environment and related management tools, Surface Command ensures your visibility is always accurate, always current, and always ready for validation.
Figure 1: Dynamic Seeds feature in the Rapid7 Command Platform
From static inventories to continuous confidence
Traditional External Attack Surface Management (EASM) tools rely on static “seed lists”, known IPs, domains, or networks used to start discovery scans. But as organizations evolve, those seeds quickly become stale, leaving blind spots that attackers can exploit.
Dynamic EASM discovery replaces static inputs with live intelligence. Surface Command, Rapid7’s attack surface management (ASM) solution, now automatically gathers seed data from across your ecosystem, including DNS records, network services, and asset repositories and feeds it directly into the Rapid7 Command Platform. Asset, vulnerability, automation, control, threat, and enrichment data are ingested into our Command Platform through Connectors.
The result: a continuously updated, validated view of your internet-facing footprint.
No spreadsheets. No manual uploads. No surprises.
Why this matters for CTEM step 2: Discovery
Continuous threat exposure management (CTEM) is the discipline of constantly discovering, prioritizing, validating, and mobilizing against risk. Most organizations excel at discovery and prioritization but validation often lags behind.
Discovery is where confidence becomes measurable:
Did the exposure we fixed actually disappear?
Is our attack surface shrinking or just shifting?
Are we making progress we can prove?
Dynamic EASM discovery strengthens step 2, discovery by ensuring your exposure data reflects the real, live environment. Every time a cloud resource changes or a new asset appears, Surface Command automatically revalidates what’s known versus what’s newly exposed.
That means your CTEM cycle is never out of sync with reality, and your reports to leadership reflect verified reductions in risk, not assumptions.
Connecting visibility to outcomes
Dynamic EASM discovery doesn’t just simplify inventory management, it accelerates progress across the CTEM lifecycle:
Discovery: Continuously ingesting data expands your external visibility.
Prioritization: Integrated context links assets to business impact and threat intelligence.
Validation: Continuous seed refresh confirms exposures are resolved and risk is reducing.
Mobilization: Validated insights flow into ITSM and automation workflows for closure.
For security leaders, this translates to clear, measurable progress: a smaller attack surface, shorter exposure windows, and data that executives can trust.
An attacker’s view you can trust
External visibility is only useful if it’s reliable. With dynamic EASM discovery, Surface Command provides a real-time, attacker’s-eye view of your organization’s public-facing assets, domains, subdomains, IPs, and network services; all validated against live data.
This level of automation gives CISOs three distinct advantages:
Fewerblind spots – Automatically capture new and transient assets the moment they appear.
Proven accuracy – Validate that remediation efforts have actually closed exposures.
Faster decisions – Operate on verified intelligence instead of lagging asset data.
Validation becomes continuous, evidence-based, and defensible.
Executive clarity through proof
Boards don’t want more alerts, they want proof that investments in security are paying off. Dynamic EASM Discovery helps CISOs demonstrate that progress with concrete, validated metrics:
Total external assets tracked over time
Exposure reduction percentages by business unit
Remediation velocity measured in real, verified outcomes
When the question comes, “are we actually reducing risk?”
Surface Command gives you evidence, not estimates.
Simplified operations, stronger security
Dynamic EASM discovery is built into Rapid7’s Command Platform, eliminating the manual effort that once slowed exposure management. Security and IT teams can focus on reducing risk instead of reconciling data sources, while automation keeps inventories and dashboards perpetually up to date.
In practice, that means:
Reduced administrative overhead
Elimination of stale or duplicate records
Seamless integration with other Command Platform services for unified CTEM execution
What used to take hours of manual input now happens automatically, at the speed your business evolves.
Continuous validation made simple
Attack surface expansion doesn’t stop, and neither should your visibility. With dynamic EASM discovery, Rapid7 ensures that the foundation of your CTEM program, discovery, is always grounded in current, accurate data.
It’s continuous assurance for a world that doesn’t stand still. This is in early access now, and generally available in January, 2026.
I recently won a lawsuit against Roy and Rianne Schestowitz, the authors and publishers of the Techrights and Tuxmachines websites. The short version of events is that they were subject to an online harassment campaign, which they incorrectly blamed me for. They responded with a large number of defamatory online posts about me, which the judge described as unsubstantiated character assassination and consequently awarded me significant damages. That’s not what this post is about, as such. It’s about the sole meaningful claim made that tied me to the abuse.
In the defendants’ defence and counterclaim[1], 15.27 asserts in part The facts linking the Claimant to the sock puppet accounts include, on the IRC network: simultaneous dropped connections to the mjg59_ and elusive_woman accounts. This is so unlikely to be coincidental that the natural inference is that the same person posted under both names. “elusive_woman” here is an account linked to the harassment, and “mjg59_” is me. This is actually a surprisingly interesting claim to make, and it’s worth going into in some more detail.
The event in question occurred on the 28th of April, 2023. You can see a line reading *elusive_woman has quit (Ping timeout: 2m30s), followed by one reading *mjg59_ has quit (Ping timeout: 2m30s). The timestamp listed for the first is 09:52, and for the second 09:53. Is that actually simultaneous? We can actually gain some more information – if you hover over the timestamp links on the right hand side you can see that the link is actually accurate to the second even if that’s not displayed. The first event took place at 09:52:52, and the second at 09:53:03. That’s 11 seconds apart, which is clearly not simultaneous, but maybe it’s close enough. Figuring out more requires knowing what a “ping timeout” actually means here.
The IRC server in question is running Ergo (link to source code), and the relevant function is handleIdleTimeout(). The logic here is fairly simple – track the time since activity was last seen from the client. If that time is longer than DefaultIdleTimeout (which defaults to 90 seconds) and a ping hasn’t been sent yet, send a ping to the client. If a ping has been sent and the timeout is greater than DefaultTotalTimeout (which defaults to 150 seconds), disconnect the client with a “Ping timeout” message. There’s no special logic for handling the ping reply – a pong simply counts as any other client activity and resets the “last activity” value and timeout.
What does this mean? Well, for a start, two clients running on the same system will only have simultaneous ping timeouts if their last activity was simultaneous. Let’s imagine a machine with two clients, A and B. A sends a message at 02:22:59. B sends a message 2 seconds later, at 02:23:01. The idle timeout for A will fire at 02:24:29, and for B at 02:24:31. A ping is sent for A at 02:24:29 and is responded to immediately – the idle timeout for A is now reset to 02:25:59, 90 seconds later. The machine hosting A and B has its network cable pulled out at 02:24:30. The ping to B is sent at 02:24:31, but receives no reply. A minute later, at 02:25:31, B quits with a “Ping timeout” message. A ping is sent to A at 02:25:59, but receives no reply. A minute later, at 02:26:59, A quits with a “Ping timeout” message. Despite both clients having their network interrupted simultaneously, the ping timeouts occur 88 seconds apart.
So, two clients disconnecting with ping timeouts 11 seconds apart is not incompatible with the network connection being interrupted simultaneously – depending on activity, simultaneous network interruption may result in disconnections up to 90 seconds apart. But another way of looking at this is that network interruptions may occur up to 90 seconds apart and generate simultaneous disconnections[2]. Without additional information it’s impossible to determine which is the case.
This already casts doubt over the assertion that the disconnection was simultaneous, but if this is unusual enough it’s still potentially significant. Unfortunately for the Schestowitzes, even looking just at the elusive_woman account, there were several cases where elusive_woman and another user had a ping timeout within 90 seconds of each other – including one case where elusive_woman and schestowitz[TR] disconnect 40 seconds apart. By the Schestowitzes argument, it’s also a natural inference that elusive_woman and schestowitz[TR] (one of Roy Schestowitz’s accounts) are the same person.
We didn’t actually need to make this argument, though. In England it’s necessary to file a witness statement describing the evidence that you’re going to present in advance of the actual court hearing. Despite being warned of the consequences on multiple occasions the Schestowitzes never provided any witness statements, and as a result weren’t allowed to provide any evidence in court, which made for a fairly foregone conclusion.
[1] As well as defending themselves against my claim, the Schestowitzes made a counterclaim on the basis that I had engaged in a campaign of harassment against them. This counterclaim failed.
[2] Client A and client B both send messages at 02:22:59. A falls off the network at 02:23:00, has a ping sent at 02:24:29, and has a ping timeout at 02:25:29. B falls off the network at 02:24:28, has a ping sent at 02:24:29, and has a ping timeout at 02:25:29. Simultaneous disconnects despite over a minute of difference in the network interruption.
Today, we are marking the 10th anniversary of the European Astro Pi Challenge.
At 11:03 on 15 December 2015, former ESA Astronaut Tim Peake launched from Baikonur cosmodrome in Kazakhstan on a Soyuz rocket as part of his UK Space agency ‘Principia’ mission to the International Space Station (ISS). Two Raspberry Pi-powered Astro Pi Mark 1 computers were waiting for him in the Columbus module of the ISS, ready to be set up for an experimental education activity called “Astro Pi”.
Tim Peake and one of the Mark 1 Astro Pi computers.
The European Astro Pi Challenge, an ESA Education project run in collaboration with the Raspberry Pi Foundation, and supported by national ESEROs, has been running every year since. The challenge now features two Python coding ‘missions’ that offer young people the amazing opportunity to write a short computer program to send to run on the ISS: Mission Zero and Mission Space Lab.
Tens of thousands of young people participate in Astro Pi annually, reaching over 160,000 participants since 2015. On 15 December this year, Tim Peake and some of the Astro Pi team were at the Science Museum London running Mission Zero workshops for visiting school groups to create their own pixel art programs to send into space.
Tim Peake with Libby Jackson at the Science Museum London
“Setting up the Astro Pi computers on the ISS for those first experiments in 2015 was just the beginning of something truly incredible — it’s amazing to see how much impact the programme has had since then! I hope Astro Pi inspires thousands more young people to code, learn about space technology, and feel empowered to reach for the stars in their own careers.” – Tim Peake, former ESA Astronaut
Astro Pi 2015–2025: A space odyssey
As the challenge has matured, its reach has increased, with over 25,000 participants every year since 2021. Young people from all 27 ESA member and associate states have sent their code into space, with 25% of mentors returning to the challenge year after year.
“I think Mission Zero is a way of connecting not only to a worldwide group of learners, but also to explorers, future scientists, and future astronauts. To see them as part of a larger community and not just an activity or assignment that they have to do in class. They discover their own abilities and potential, and exercise their creativity in a very low-stakes environment and then to see it come to life in that global way is extremely valuable.” – Mission Zero mentor
Mission Zero has proved to be a great way to engage girls in computing and tech, with an average of 44% of participants identifying as female. This is well above the national averages for other STEM subjects in many countries.
What attracts many teams of young people to Mission Space Lab is the chance to capture data and images from the SenseHats and High Quality Cameras on the Astro Pi computers. This year the Astro Pis will be positioned in the World Observation Research Facility (WORF) window, which means teams can hope for some fantastic, high-quality Earth-observation images with a full field of view. Each team that achieves Flight Status will receive the images and data their program captures.
Photo of the Gulf of California captured from the WORF window by team ByndTSky, and the Astro Pis situated in WORF
The next generation of space explorers
Astro Pi is one of the most inspirational coding activities that young people can do and gives the exciting chance to reach beyond the boundaries of what they may have thought possible. In the 2024–25 impact report, mentors reported that the young people participating were highly motivated by the possibility of having their code run on the ISS.
“Honestly, the idea that a kid can send their own code to space is just mind-blowing. It really makes you rethink what ‘possible’ even means.” – Jeanna, Astro Pi enthusiast
A selection Mission Zero submissions from 2024–25
Participation increases skills, confidence and motivation for further exploration in coding, digital making and STEM subjects.
83% of Mission Zero mentors agreed that young people increased their skills and confidence in computing and digital making due to their participation
91% of mentors told us that young people who successfully wrote code for Mission Space Lab were likely, or very likely, to participate in computing and digital making challenges in the future
Join us in this year’s anniversary challenge to celebrate a decade of sending young people’s code into space – and receive some limited edition certificates. You can find out everything you need to participate or to mentor a team at astro-pi.org.
For two days in September, Afghanistan had no internet. No satellite failed; no cable was cut. This was a deliberate outage, mandated by the Taliban government. It followed a more localized shutdown two weeks prior, reportedly instituted “to prevent immoral activities.” No additional explanation was given. The timing couldn’t have been worse: communities still reeling from a major earthquake lost emergency communications, flights were grounded, and banking was interrupted. Afghanistan’s blackout is part of a wider pattern. Just since the end of September, there were also major nationwide internet shutdowns in Tanzania and Cameroon, and significant regional shutdowns in Pakistan and Nigeria. In all cases but one, authorities offered no official justification or acknowledgment, leaving millions unable to access information, contact loved ones, or express themselves through moments of crisis, elections, and protests.
The frequency of deliberate internet shutdowns has skyrocketed since the first notable example in Egypt in 2011. Together with our colleagues at the digital rights organisation Access Now and the #KeepItOn coalition, we’ve tracked 296 deliberate internet shutdowns in 54 countries in 2024, and at least 244 more in 2025 so far.
This is more than an inconvenience. The internet has become an essential piece of infrastructure, affecting how we live, work, and get our information. It’s also a major enabler of human rights, and turning off the internet can worsen or conceal a spectrum of abuses. These shutdowns silence societies, and they’re getting more and more common.
Shutdowns can be local or national, partial or total. In total blackouts, like Afghanistan or Tanzania, nothing works. But shutdowns are often targeted more granularly. Cellphone internet could be blocked, but not broadband. Specific news sites, social media platforms, and messaging systems could be blocked, leaving overall network access unaffected—as when Brazil shut off X (formerly Twitter) in 2024. Sometimes bandwidth is just throttled, making everything slower and unreliable.
Sometimes, internet shutdowns are used in political or military operations. In recent years, Russia and Ukraine have shut off parts of each other’s internet, and Israel has repeatedly shut off Palestinians’ internet in Gaza. Shutdowns of this type happened 25 times in 2024, affecting people in 13 countries.
Reasons for the shutdowns are as varied as the countries that perpetrate them. General information control is just one. Shutdowns often come in response to political unrest, as governments try to prevent people from organizing and getting information; Panama had a regional shutdown this summer in response to protests. Or during elections, as opposition parties utilize the internet to mobilize supporters and communicate strategy. Belarusian president Alyaksandr Lukashenko, who has ruled since 1994, reportedly disabled the internet during elections earlier this year, following a similar move in 2020. But they can also be more banal. Access Now documented countries disabling parts of the internet during student exam periods at least 16 times in 2024, including Algeria, Iraq, Jordan, Kenya, and India.
Iran’s shutdowns in 2022 and June of this year are good examples of a highly sophisticated effort, with layers of shutdowns that end up forcing people off the global internet and onto Iran’s surveilled, censored national intranet. India, meanwhile, has been the world shutdown leader for many years, with 855 distinct incidents. Myanmar is second with 149, followed by Pakistan and then Iran. All of this information is available on Access Now’s digital dashboard, where you can see breakdowns by region, country, type, geographic extent, and time.
There was a slight decline in shutdowns during the early years of the pandemic, but they have increased sharply since then. The reasons are varied, but a lot can be attributed to the rise in protest movements related to economic hardship and corruption, and general democratic backsliding and instability. In many countries today, shutdowns are a knee-jerk response to any form of unrest or protest, no matter how small.
A country’s ability to shut down the internet depends a lot on its infrastructure. In the US, for example, shutdowns would be hard to enforce. As we saw when discussions about a potential TikTok ban ramped up two years ago, the complex and multifaceted nature of our internet makes it very difficult to achieve. However, as we’ve seen with total nationwide shutdowns around the world, the ripple effects in all aspects of life are immense. (Remember the effects of just a small outage—CrowdStrike in 2024—which crippled 8.5 million computers and cancelled 2,200 flights in the US alone?)
The more centralized the internet infrastructure, the easier it is to implement a shutdown. If a country has just one cellphone provider, or only two fiber optic cables connecting the nation to the rest of the world, shutting them down is easy.
Shutdowns are not only more common, but they’ve also become more harmful. Unlike in years past, when the internet was a nice option to have, or perhaps when internet penetration rates were significantly lower across the Global South, today the internet is an essential piece of societal infrastructure for the majority of the world’s population.
Access Now has long maintained that denying people access to the internet is a human rights violation, and has collected harrowing stories from places like Tigray in Ethiopia, Uganda, Annobon in Equatorial Guinea, and Iran. The internet is an essential tool for a spectrum of rights, including freedom of expression and assembly. Shutdowns make documenting ongoing human rights abuses and atrocities more difficult or impossible. They are also impactful on people’s daily lives, business, healthcare, education, finances, security, and safety, depending on the context. Shutdowns in conflict zones are particularly damaging, as they impact the ability of humanitarian actors to deliver aid and make it harder for people to find safe evacuation routes and civilian corridors.
Defenses on the ground are slim. Depending on the country and the type of shutdown, there can be workarounds. Everything, from VPNs to mesh networks to Starlink terminals to foreign SIM cards near borders, has been used with varying degrees of success. The tech-savvy sometimes have other options. But for most everyone in society, no internet means no internet—and all the effects of that loss.
The international community plays an important role in shaping how internet shutdowns are understood and addressed. World bodies have recognized that reliable internet access is an essential service, and could put more pressure on governments to keep the internet on in conflict-affected areas. But while international condemnation has worked in some cases (Mauritius and South Sudan are two recent examples), countries seem to be learning from each other, resulting in both more shutdowns and new countries perpetrating them.
There’s still time to reverse the trend, if that’s what we want to do. Ultimately, the question comes down to whether or not governments will enshrine both a right to access information and freedom of expression in law and in practice. Keeping the internet on is a norm, but the trajectory from a single internet shutdown in 2011 to 2,000 blackouts 15 years later demonstrates how embedded the practice has become. The implications of that shift are still unfolding, but they reach far beyond the moment the screen goes dark.
This essay was written with Zach Rosson, and originally appeared in Gizmodo.
И на дъжда да устоя, и на вятъра да устоя, и на снега, и на летните жеги. Да имам здраво тяло, за нищо да не ламтя, изобщо да не се гневя и винаги да съм усмихнат. Три купички ориз на ден, малко супа и зеленчуци. Да гледам да не се тревожа, да наблюдавам и да слушам, да разбирам и да не забравям. Стига ми сламена колиба под сянката на борова гора. На изток боледува ли дете, отивам да се грижа. На запад ако има уморена майка, да ѝ помогна. На юг ако умира някой, да му кажа да не се бои. На север ако спорят, да се опитам да ги помиря. Когато е суша, да проливам сълзи. А в дъждовно лято да съм угрижен. Нека да ме мислят за глупак, да не ме ласкаят, нито да ме съдят. Ето такъв човек искам да бъда.
Кенджи Миядзава
Кенджи Миядзава (1896–1933) е японски поет и писател, известен със своите фантастични разкази за деца. Задълбочените му духовни търсения бележат както начина му на живот, така и писането му. Приживе публикува малко, но след смъртта си се превръща в един от най-обичаните автори в Япония. Днес неговите стихотворения и разкази са част от класиката на модерната японска литература.
Елвира Цветанова е завършила специалност „Японистика“ в СУ „Св. Климент Охридски“ и е специализирала в Университета Ибараки в Япония. В момента преподава японски език в Плевен и продължава обучението си в областта на литературата в магистърската програма „Комуникация: език, литература, медии“ на СУ „Св. Климент Охридски“.
Версията на превода на стихотворението на Кенджи Миядзава е плод на задълбочено обсъждане и редактиране в рамките на професионален семинар към Къщата за литература и превод, София.
Според Екатерина Йосифова „четящият стихотворение сутрин… добре понася другите часове“ от деня. Убедени, че поезията държи умовете ни будни, а сърцата – отворени, в края на всеки месец ви предлагаме по едно стихотворение. Защото и в най-смутни времена доброто стихотворение е добра новина.
Amazon GuardDuty and our automated security monitoring systems identified an ongoing cryptocurrency (crypto) mining campaign beginning on November 2, 2025. The operation uses compromised AWS Identity and Access Management (IAM) credentials to target Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Compute Cloud (Amazon EC2). GuardDuty Extended Threat Detection was able to correlate signals across these data sources to raise a critical severity attack sequence finding. Using the massive, advanced threat intelligence capability and existing detection mechanisms of Amazon Web Services (AWS), GuardDuty proactively identified this ongoing campaign and quickly alerted customers to the threat. AWS is sharing relevant findings and mitigation guidance to help customers take appropriate action on this ongoing campaign.
It’s important to note that these actions don’t take advantage of a vulnerability within an AWS service but rather require valid credentials that an unauthorized user uses in an unintended way. Although these actions occur in the customer domain of the shared responsibility model, AWS recommends steps that customers can use to detect, prevent, or reduce the impact of such activity.
Understanding the crypto mining campaign
The recently detected crypto mining campaign employed a novel persistence technique designed to disrupt incident response and extend mining operations. The ongoing campaign was originally identified when GuardDuty security engineers discovered similar attack techniques being used across multiple AWS customer accounts, indicating a coordinated campaign targeting customers using compromised IAM credentials.
Operating from an external hosting provider, the threat actor quickly enumerated Amazon EC2 service quotas and IAM permissions before deploying crypto mining resources across Amazon EC2 and Amazon ECS. Within 10 minutes of the threat actor gaining initial access, crypto miners were operational.
A key technique observed in this attack was the use of ModifyInstanceAttribute with disable API termination set to true, forcing victims to re-enable API termination before deleting the impacted resources. Disabling instance termination protection adds an additional consideration for incident responders and can disrupt automated remediation controls. The threat actor’s scripted use of multiple compute services, in combination with emerging persistence techniques, represents an advancement in crypto mining persistence methodologies that security teams should be aware of.
The multiple detection capabilities of GuardDuty successfully identified the malicious activity through EC2 domain/IP threat intelligence, anomaly detection, and Extended Threat Detection EC2 attack sequences. GuardDuty Extended Threat Detection was able to correlate signals as an AttackSequence:EC2/CompromisedInstanceGroup finding.
Indicators of compromise (IoCs)
Security teams should monitor for the following indicators to identify this crypto mining campaign. Threat actors frequently modify their tactics and techniques, so these indicators might evolve over time:
Malicious container image – The Docker Hub image yenik65958/secret, created on October 29, 2025, with over 100,000 pulls, was used to deploy crypto miners to containerized environments. This malicious image contained a SBRMiner-MULTI binary for crypto mining. This specific image has been taken down from Docker Hub, but threat actors might deploy similar images under different names.
Automation and tooling – AWS SDK for Python (Boto3) user agent patterns indicating Python-based automation scripts were used across the entire attack chain.
Crypto mining domains:asia[.]rplant[.]xyz, eu[.]rplant[.]xyz, and na[.]rplant[.]xyz.
Infrastructure naming patterns – Auto scaling groups followed specific naming conventions: SPOT-us-east-1-G*-* for spot instances and OD-us-east-1-G*-* for on-demand instances, where G indicates the group number.
Attack chain analysis
The crypto mining campaign followed a systematic attack progression across multiple phases. Sensitive fields in this post were given fictitious values to protect personally identifiable information (PII).
Figure 1: Cryptocurrency mining campaign diagram
Initial access, discovery, and attack preparation
The attack began with compromised IAM user credentials possessing admin-like privileges from an anomalous network and location, triggering GuardDuty anomaly detection findings. During the discovery phase, the attacker systematically probed customer AWS environments to understand what resources they could deploy. They checked Amazon EC2 service quotas (GetServiceQuota) to determine how many instances they could launch, then tested their permissions by calling the RunInstances API multiple times with the DryRun flag enabled.
The DryRun flag was a deliberate reconnaissance tactic that allowed the actor to validate their IAM permissions without actually launching instances, avoiding costs and reducing their detection footprint. This technique demonstrates the threat actor was validating their ability to deploy crypto mining infrastructure before acting. Organizations that don’t typically use DryRun flags in their environments should consider monitoring for this API pattern as an early warning indicator of compromise. AWS CloudTrail logs can be used with Amazon CloudWatchalarms, Amazon EventBridge, or your third-party tooling to alert on these suspicious API patterns.
The threat actor called two APIs to create IAM roles as part of their attack infrastructure: CreateServiceLinkedRole to create a role for auto scaling groups and CreateRole to create a role for AWS Lambda. They then attached the AWSLambdaBasicExecutionRole policy to the Lambda role. These two roles were integral to the impact and persistence stages of the attack.
Amazon ECS impact
The threat actor first created dozens of ECS clusters across the environment, sometimes exceeding 50 ECS clusters in a single attack. They then called RegisterTaskDefinition with a malicious Docker Hub image yenik65958/secret:user. With the same string used for the cluster creation, the actor then created a service, using the task definition to initiate crypto mining on ECS AWS Fargate nodes. The following is an example of API request parameters for RegisterTaskDefinition with a maximum CPU allocation of 16,384 units.
Figure 2: Contents of the cryptocurrency mining script within the malicious image
The malicious image (yenik65958/secret:user) was configured to execute run.sh after it has been deployed. run.sh runs randomvirel mining algorithm with the mining pools: asia|eu|na[.]rplant[.]xyz:17155. The flag nproc --all indicates that the script should use all processor cores.
Amazon EC2 impact
The actor created two launch templates (CreateLaunchTemplate) and 14 auto scaling groups (CreateAutoScalingGroup) configured with aggressive scaling parameters, including a maximum size of 999 instances and desired capacity of 20. The following example of request parameters from CreateLaunchTemplate shows the UserData was supplied, instructing the instances to begin crypto mining.
The threat actor created auto scaling groups using both Spot and On-Demand Instances to make use of both Amazon EC2 service quotas and maximize resource consumption.
Spot Instance groups:
Targeted high performance GPU and machine learning (ML) instances (g4dn, g5, g5, p3, p4d, inf1)
Configured with 0% on-demand allocation and capacity-optimized strategy
After exhausting auto scaling quotas, the actor directly launched additional EC2 instances using RunInstances to consume the remaining EC2 instance quota.
Persistence
An interesting technique observed in this campaign was the threat actor’s use of ModifyInstanceAttribute across all launched EC2 instances to disable API termination. Although instance termination protection prevents accidental termination of the instance, it adds an additional consideration for incident response capabilities and can disrupt automated remediation controls. The following example shows request parameters for the API ModifyInstanceAttribute.
After all mining workloads were deployed, the actor created a Lambda function with a configuration that bypasses IAM authentication and creates a public Lambda endpoint. The threat actor then added a permission to the Lambda function that allows the principal to invoke the function. The following examples show CreateFunctionUrlConfig and AddPermission request parameters.
To prevent public Lambda URLs from being created, organizations can deploy service control policies (SCPs) that deny creation or updating of Lambda URLs with an AuthType of “NONE”.
The multilayered detection approach of GuardDuty proved highly effective in identifying all stages of the attack chain using threat intelligence, anomaly detection, and the recently launched Extended Threat Detection capabilities for EC2 and ECS.
Next, we walk through the details of these features and how you can deploy them to detect attacks such as these. You can enable GuardDuty foundational protection plan to receive alerts on crypto mining campaigns like the one described in this post. To further enhance detection capabilities, we highly recommend enabling GuardDuty Runtime Monitoring, which will extend finding coverage to system-level events on Amazon EC2, Amazon ECS, and Amazon Elastic Kubernetes Service (Amazon EKS).
GuardDuty EC2 findings
Threat intelligence findings for Amazon EC2 are part of the GuardDuty foundational protection plan, which will alert you to suspicious network behaviors involving your instances. These behaviors can include brute force attempts, connections to malicious or crypto domains, and other suspicious behaviors. Using third-party threat intelligence and internal threat intelligence, including active threat defense and MadPot, GuardDuty provides detection over the indicators in this post through the following findings: CryptoCurrency:EC2/BitcoinTool.B and CryptoCurrency:EC2/BitcoinTool.B!DNS.
GuardDuty IAM findings
The IAMUser/AnomalousBehavior findings spanning multiple tactic categories (PrivilegeEscalation, Impact, Discovery) showcase the ML capability of GuardDuty to detect deviations from normal user behavior. In the incident described in this post, the compromised credentials were detected due to the threat actor using them from an anomalous network and location and calling APIs that were unusual for the accounts.
GuardDuty Runtime Monitoring
GuardDuty Runtime Monitoring is an important component for Extended Threat Detection attack sequence correlation. Runtime Monitoring provides host level signals, such as operating system visibility, and extends detection coverage by analyzing system-level logs indicating malicious process execution at the host and container level, including the execution of crypto mining programs on your workloads. The CryptoCurrency:Runtime/BitcoinTool.B!DNS and CryptoCurrency:Runtime/BitcoinTool.B findings detect network connections to crypto-related domains and IPs, while the Impact:Runtime/CryptoMinerExecuted finding detects when a process running is associated with a cryptocurrency mining activity.
GuardDuty Extended Threat Detection
Launched at re:Invent 2025, AttackSequence:EC2/CompromisedInstanceGroup finding represents one of the latest Extended Threat Detection capabilities in GuardDuty. This feature uses AI and ML algorithms to automatically correlate security signals across multiple data sources to detect sophisticated attack patterns of EC2 resource groups. Although AttackSequences for EC2 are included in the GuardDuty foundational protection plan, we strongly recommend enabling Runtime Monitoring. Runtime Monitoring provides key insights and signals from compute environments, enabling detection of suspicious host-level activities and improving correlation of attack sequences. For AttackSequence:ECS/CompromisedCluster attack sequences, Runtime Monitoring is required to correlate container-level activity.
Monitoring and remediation recommendations
To protect against similar crypto mining attacks, AWS customers should prioritize strong identity and access management controls. Implement temporary credentials instead of long-term access keys, enforce multi-factor authentication (MFA) for all users, and apply least privilege to IAM principals limiting access to only required permissions. You can use AWS CloudTrail to log events across AWS services and combine logs into a single account to make them available to your security teams to access and monitor. To learn more, refer to Receiving CloudTrail log files from multiple accounts in the CloudTrail documentation.
Confirm GuardDuty is enabled across all accounts and Regions with Runtime Monitoring enabled for comprehensive coverage. Integrate GuardDuty with AWS Security Hub and Amazon EventBridge or third-party tooling to enable automated response workflows and rapid remediation of high-severity findings. Implement container security controls, including image scanning policies and monitoring for unusual CPU allocation requests in ECS task definitions. Finally, establish specific incident response procedures for crypto mining attacks, including documented steps to handle instances with disabled API termination—a technique used by this attacker to complicate remediation efforts.
Organizations today face a critical challenge with fragmented data scattered across multiple silos, including data lakes, warehouses, SaaS applications, and legacy systems. This disconnect prevents businesses from gaining a holistic view of their customers, optimizing operations, and making real-time data-driven decisions. To stay competitive, companies are turning to self-service analytics, enabling both business and technical users to quickly access, explore, and analyze data without dependency on IT teams.
However, implementing self-service analytics comes with significant challenges. Organizations must address integrating data from diverse sources for seamless access, creating business and technical catalogs to improve data discoverability, enabling data lineage and quality to build trust and reliability, implementing fine-grained access controls to ensure security and compliance, providing role-specific tools for data engineers, analysts, and artificial intelligence (AI)/machine learning (ML) teams, and establishing governance frameworks to enforce policies and regulatory requirements.
In this post, we show how to use Amazon SageMaker Catalog to publish data from multiple sources, including Amazon S3, Amazon Redshift, and Snowflake. This approach enables self-service access while ensuring robust data governance and metadata management. By centralizing metadata, users can improve data discoverability, lineage tracking, and compliance while empowering analysts, data engineers, and data scientists to derive AI-driven insights efficiently and securely. We use a sample retail use case to demonstrate the solution, making it easier to understand how these capabilities can be applied to real-world scenarios.
Amazon SageMaker: Enabling self-service analytics
Amazon SageMaker brings together AWS AI/ML and analytics capabilities, delivering an integrated experience for analytics and AI with unified data access, enabling teams to:
Discover and access data stored across Amazon S3, Amazon Redshift, and other third-party sources through the Lakehouse architecture.
Perform complete AI and analytics workflows using familiar AWS services for data analysis, processing, model training, and generative AI app development.
Use Amazon Q Developer, an advanced generative AI assistant to accelerate software development.
Ensure enterprise-grade security with built-in governance, fine-grained access controls, and secure artifact sharing with Amazon SageMaker Catalog.
Collaborate in shared projects, allowing teams to work together efficiently while maintaining compliance and governance.
Retail use case overview
In our example, a retail organization operates across multiple business units, each storing data in different platforms, creating challenges in data access, consistency, and governance.
Figure 1: High-level architecture of our retail use case showing data flow across multiple systems
Our retail organization faces data fragmentation across its business units:
The Wholesale Sales business unit stores its data in Amazon S3.
The Store Sales business unit maintains its transactional data in Amazon Redshift.
Online Sales Data is stored in Snowflake.
These disparate data sources result in data silos, inconsistent schemas, duplication, and missing values, making it difficult for analysts and AI-driven solutions to derive meaningful insights.
Data model
The following Entity-Relationship (ER) Diagram represents the dataset structure and relationships between different entities in Wholesale, Retail, and Online Sales Data:
Figure 2: Entity-Relationship Diagram showing the relationships between different data entities
Key entities in our data model
Our sample dataset models a multi-channel retail business with interconnected entities representing products, sales channels, customers, and locations.
PRODUCTS is a central entity that links to WHOLESALE_SALES, RETAIL_SALES, and ONLINE_SALES, representing product transactions across different sales channels.
WHOLESALE_SALES records bulk transactions where WAREHOUSES distribute products to retailers. Each sale is associated with a PRODUCT and a WAREHOUSE.
RETAIL_SALES captures individual purchases made in physical STORES. Each transaction involves a PRODUCT and a STORE, along with details like quantity sold, discount applied, and revenue.
ONLINE_SALES tracks e-commerce transactions where customers buy products online. Each record links to a CUSTOMER and a PRODUCT, along with details like quantity, price, and shipping information.
CUSTOMERS represent buyers in the system and are linked to ONLINE_SALES (for purchasing) and CUSTOMER_REVIEWS (for leaving product reviews).
CUSTOMER_REVIEWS stores feedback provided by customers for products they purchased online. Each review is linked to an ONLINE_SALES order, a CUSTOMER, and a PRODUCT.
STORES represent physical retail locations where products are sold. They are associated with RETAIL_SALES, indicating that products are purchased in-store.
WAREHOUSES are responsible for stocking and distributing products through WHOLESALE_SALES transactions. They manage stock levels and facilitate bulk sales to retailers.
Data distribution across systems
To simulate a real-world enterprise scenario, our data is distributed across multiple systems and AWS accounts as follows:
Accounts
Location
Tables
Wholesale
Amazon S3
WHOLESALE_SALES, PRODUCT, WAREHOUSE
Store
Amazon Redshift
RETAIL_SALES, STORE, PRODUCT
Online Sales
Snowflake
ONLINE_SALES, CUSTOMER, CUSTOMER_REVIEWS, PRODUCT
Assumptions
We are making the following assumptions for this implementation.
Three AWS accounts: Wholesale account, Store account, and Centralized Processing account.
In this section, we walk through the process of creating the SageMaker Catalog from multiple sources using Amazon SageMaker Unified Studio.
Step 1: Setting up your SageMaker Unified Studio environment
Before we begin building our data catalog, we cover some terminology for SageMaker Unified Studio.
Domain: A domain in Amazon SageMaker Unified Studio is a logical boundary that serves as the primary container for all your data assets, users, and resources, allowing efficient data organization and management. Domain Units: Domain units are subcomponents within a domain that help organize related projects and resources together, enabling hierarchical structuring of your data management activities. Blueprint: A blueprint in Amazon SageMaker Unified Studio is a template that defines standardized configurations for projects, including what resources are provisioned, and what tools, and parameters are applied. Project Profile: A project profile is a collection of blueprints which are configurations used to create projects. A project profile can define if a particular blueprint is enabled during the creation of the project, or available later for the project users to enable on-demand. Project: A project in Amazon SageMaker Unified Studio is a boundary within a domain where users can collaborate with others to work on a business use case. In projects, users can create and share data and resources.
Now, we can set up our Amazon SageMaker Unified Studio environment.
Create a SageMaker domain
Open the Amazon SageMaker management console in the Centralized Processing account and use the region selector in the top navigation bar to choose the appropriate AWS Region.
For Create IAM Identity Center User, search for SSO users through email addresses. If there is no Amazon Identity Access Manager (IAM) Identity Center instance, a prompt appears to enter your name after your email address. This creates a new local IAM Identity Center instance.
Choose Create domain.
Log in to SageMaker Unified Studio
Now that we have created a new SageMaker Unified Studio domain, complete the following steps to visit the Amazon SageMaker Unified Studio.
On the SageMaker platform console, open the details page of your domain.
Choose the link for Amazon SageMaker Unified Studio URL.
Log in with your SSO credentials.
Now you signed in to the SageMaker Unified Studio.
Create a project
The next step is to create a project. Complete the following steps:
On the SageMaker Unified Studio, choose Select a project on the top menu, and choose Create project.
For Project name, enter a name (such as AnyCompanyDataPlatform).
For Project profile, choose All capabilities.
Choose Continue.
Review the input and choose Create project. This project serves as a collaborative workspace for our data integration efforts.
Wait for the project to be created. Project creation can take about five minutes. Then The SageMaker Unified Studio console goes to the project’s home page.
Step 2: Connecting to data sources
Now, we connect to our various data sources to bring them into our data catalog.
Importing existing AWS Glue Data Catalog (Wholesale Sales Data)
We first import the wholesale sales data from Amazon S3 in the Wholesale account into Amazon SageMaker Unified Studio.
Set up cross-account access
Log in to Centralized Processing account and create a Glue Crawler role named glue-cross-s3-access with the AWSGlueServiceRole and cross account S3 access policy for Wholesale account. Sample cross account S3 access policy:
Log in to the Wholesale account and create an S3 bucket policy that grants access to S3 data files for the previously created glue-cross-s3-access role of the Centralized Processing account.
Log in to the Centralized Processing account and create a database named anycompanydatacatlog from the AWS Glue.
Grant permissions to the glue-cross-s3-access role for the anycompanydatacatalog database in AWS Lake Formation.
Run the Glue Crawler using the glue-cross-s3-access role to scan the S3 bucket in the Wholesale account. For more information, refer to the tutorial explaining how to catalog S3 data using the Glue crawler.
Verify the anycompanydatacatlog database and its corresponding tables.
Copy the Amazon SageMaker Unified Studio project role ARN from project overview section.
Add the same Amazon SageMaker Unified Studio project role as LakeFormation Data Lake Administrator.
Import the assets into Amazon SageMaker Unified Studio
Open AWS CloudShell in the Centralized Processing account console.
Upload the previously downloaded bring_your_own_gdc_assets.py file to AWS CloudShell.
Run the import script in AWS CloudShell with following parameters.
project-role-arn: Enter the project role ARN of SageMaker Unified Studio.
database-name: Enter the database name of Glue Catalog (such as anycompanydatacatalog).
region: Enter the region of SageMaker Unified Studio (such as us-east-1).
python3 bring_your_own_gdc_assets.py \
--project-role-arn <Project role ARN> \
--database-name <Glue Database name to import> \
--region <region-code>
Verify the imported wholesale sales data
In the Centralized Processing account, go to the SageMaker Unified Studio console, choose your project.
Choose Data in the navigation pane.
Confirm that the wholesale_db database and its tables (WHOLESALE_SALES, PRODUCT, WAREHOUSE) are now available under anycompanydatacatalog.
Connecting to Amazon Redshift (Stores sales data)
In this step, we bring stores sales data from Amazon Redshift in the Store account into Amazon SageMaker Unified Studio.
Set up cross-account access
Login to the Store account, create a virtual private cloud (VPC) peering connection between the Store account and the Centralized Processing account, which hosts the Amazon SageMaker Unified Studio, and configure route tables following the documentation.
Update your Redshift VPC security group’s rule to include the Centralized Processing account’s IPv4 CIDR range, enabling network connectivity and allowing incoming requests from the Centralized Processing account to access the Store account resources.
Create a federated connection for Amazon Redshift
In the Centralized Processing account, go to the SageMaker Unified Studio console, choose your project.
Choose Data in the navigation pane.
In the data explorer, choose the plus sign to add a data source.
Under add a data source, choose Add connection, then choose Amazon Redshift.
Enter the following parameters in the connection details, and choose Add data.
Name: Enter the connection name (such as anycompanyredshift).
Host: Enter the Amazon Redshift cluster endpoint.
Port: Enter the port number (Amazon Redshift uses 5439 as the default port).
Database: Enter the database name
Authentication: Choose either the database username and password credentials or AWS Secrets Manager. We recommend using AWS Secrets Manager.
After the connection is established, the federated catalog is created, as shown in the following screenshot. This catalog uses the AWS Glue connection to Amazon Redshift. The databases, tables, and views are automatically cataloged in the catalog section and registered with Lake Formation.
Verify the stores sales data
Visit the Catalog section in SageMaker Unified Studio.
Confirm that the retails sales public database and its tables (RETAIL_SALES, STORE, PRODUCT) are now available.
Connecting to Snowflake (online sales data)
In this step, we bring online sales data from Snowflake into Amazon SageMaker Unified Studio.
Create a federated connection for Snowflake
In the Centralized Processing account, go to the SageMaker Unified Studio console, choose your project.
Choose Data in the Navigation Pane.
In the data explorer, choose the plus sign (+) to add a data source.
Under Add a data source, choose Add connection, then choose Snowflake.
Enter the following parameters in the connection details, and choose Add data.
Name: Enter the connection name (such as anycompanysnowflake).
Host: Enter the Snowflake cluster endpoint.
Port: Enter the port number (Snowflake uses 443 as the default port).
Database: Enter the database name (such as anycompanyonlinesales).
Warehouse: Enter the warehouse name (such as COMPUTE_WH).
Authentication: Choose either the database username and password credentials or Secrets Manager.
After the connection is established, the federated catalog is created for Snowflake. This catalog uses the AWS Glue connection to Snowflake. The databases, tables, and views are automatically cataloged in the Data Catalog and registered with Lake Formation.
Verify the online sales data
Go to the Catalog section in SageMaker Unified Studio.
Confirm that the Online sales public database and its tables (CUSTOMER_REVIEWS, CUSTOMER, ONLINE_SALES, PRODUCT) are now available.
Step 3: Analyze the data together
Once all the data from different data sources has been cataloged, we can analyze it using Amazon Athena query engine from Amazon SageMaker Unified Studio.
In the Centralized Processing account, go to the SageMaker Unified Studio console, choose your project.
Choose Query Editor from the Build section.
Select Athena (Lakehouse) as a connection.
Run queries joining multiple data source catalogs to analyze the data.
Example: What is the total revenue generated from wholesale, retail, and online sales for each product?
SELECT p.product_id, p.product_name, COALESCE(SUM(ws.total_revenue), 0) AS wholesale_revenue, COALESCE(SUM(rs.revenue), 0) AS retail_revenue, COALESCE(SUM(os.sale_price * os.quantity_sold), 0) AS online_revenue, (COALESCE(SUM(ws.total_revenue), 0) + COALESCE(SUM(rs.revenue), 0) + COALESCE(SUM(os.sale_price * os.quantity_sold), 0)) AS total_revenueFROM awsdatacatalog.anycompanydatacatalog.anycompany_products pLEFT JOIN awsdatacatalog.anycompanydatacatalog.anycompany_wholessale_sales ws ON p.product_id = ws.product_idLEFT JOIN anycompanyredshift.public.retail_sales rs ON p.product_id = rs.product_idLEFT JOIN anycompanysnowflake.sales.online_sales os ON p.product_id = os.product_idGROUP BY p.product_id, p.product_nameORDER BY total_revenue DESC;
Similarly, users can derive valuable business insights by querying across catalogs for different analytical questions.
Step 4: Creating a Business Glossary
A business glossary helps standardize terminology across the organization and makes data more discoverable. Now we create a business glossary for Wholesale data PRODUCT.
In the Navigation Pane, choose Data and select Publish to Catalog for the Wholesale data PRODUCT table.
Choose Assets and choose the products table.
Create a Glossary named ‘Product‘ and a Term named ‘Sales‘ from Metadata entities.
Choose Generate Descriptions to automatically generate summary of your data using AI. Choose Add Terms.
Choose ACCEPT ALL for Automated Metadata Generation.
Choose sales term and choose Add Terms.
Choose Publish Asset.
Choose Assets and then Published. We can now see a published asset that is searchable and available to request for subscription.
Similarly, you can create business glossaries for other data products by following the above steps.
Step 5: Setting up access controls
To ensure proper governance, set up fine-grained access controls.
For each user create a new single sign-on (SSO) user
Create the following roles and permissions to attach to the SSO user:
Role
Description
Access Level
Data Steward
Manages the data catalog and glossary
Full access to catalog and glossary
ETL Developer
Develops data integration pipelines
Read/write access to data sources and AWS Glue
Data Analyst
Analyzes sales data
Read-only access to all sales data
AI Engineer
Builds forecasting models
Read access to sales data, full access to SageMaker features
Benefits of SageMaker Catalog
By implementing a self-service business data catalog using Amazon SageMaker Unified Studio, our retail organization achieves several key benefits:
Unified data access: Users can discover and access data from Amazon S3, Redshift, and Snowflake through a single interface.
Standardized metadata: The business glossary ensures consistent terminology across the organization.
Governance and compliance: Fine-grained access controls ensure that users only access data they’re authorized to see.
Collaboration: Different teams (ETL developers, data analysts, AI engineers) can collaborate within a shared environment.
Cleanup
To avoid incurring additional charges associated with the resources created in this post, make sure to delete the following items from your AWS account:
The Amazon S3 bucket associated with the Amazon SageMaker domain.
Cross-account resources such as VPC peering connections, security groups, route tables, AWS Glue Data Catalog entries, and associated IAM roles4. The tables and databases created in this post.
Conclusion
In this post, we demonstrated how Amazon SageMaker Catalog provides a unified approach to data publishing, discovery, and analysis across multiple data sources. Using a retail scenario, we showed how to import data from Amazon S3, Amazon Redshift, and Snowflake into Amazon SageMaker Unified Studio, and how to join and analyze data from these multiple sources to derive meaningful business insights.
By centralizing metadata and enabling cross-source data integration, data is easily discovered across an organization, multiple data sources can be joined and comprehensive analysis performed without moving or duplicating data. This unified approach maintains strong governance with consistent policies, security, and compliance across all data sources while enabling self-service analytics that reduce time-to-insight for your teams.
Mozilla has announced
a new CEO, Anthony Enzor-DeMeo. Prior to becoming CEO, Enzor-DeMeo was
general manager of Firefox and led its “vision, strategy, and
business performance“. He has published
a blog post about taking over from interim CEO Laura Chambers, and
his plans for Mozilla and Firefox:
As Mozilla moves forward, we will focus on becoming the trusted
software company. This is not a slogan. It is a direction that guides
how we build and how we grow. It means three things.
First: Every product we build must give people agency in how it works. Privacy, data use, and AI must be clear and understandable. Controls must be simple. AI should always be a choice — something people can easily turn off. People should know why a feature works the way it does and what value they get from it.
Second: our business model must align with trust. We will grow through transparent monetization that people recognize and value.
Third: Firefox will grow from a browser into a broader
ecosystem of trusted software. Firefox will remain our anchor. It
will evolve into a modern AI browser and support a portfolio of
new and trusted software additions.
The final part of the 2025 Maintainers Summit was devoted to the kernel’s
development process itself. There were two sessions, one on continuity and
succession planning, and the traditional discussion, led by Linus Torvalds,
on any pain points that the community is experiencing. There was not a lot
that developers were unhappy about, and there are now more explicit plans in
the works to provide a process should Torvalds abruptly become unable to
fill his role.
China is already the world’s largest exporter of AI powered surveillance technology; new surveillance technologies and platforms developed in China are also not likely to simply stay there. By exposing the full scope of China’s AI driven control apparatus, this report presents clear, evidence based insights for policymakers, civil society, the media and technology companies seeking to counter the rise of AI enabled repression and human rights violations, and China’s growing efforts to project that repression beyond its borders.
The report focuses on four areas where the CCP has expanded its use of advanced AI systems most rapidly between 2023 and 2025: multimodal censorship of politically sensitive images; AI’s integration into the criminal justice pipeline; the industrialisation of online information control; and the use of AI enabled platforms by Chinese companies operating abroad. Examined together, those cases show how new AI capabilities are being embedded across domains that strengthen the CCP’s ability to shape information, behaviour and economic outcomes at home and overseas.
Because China’s AI ecosystem is evolving rapidly and unevenly across sectors, we have focused on domains where significant changes took place between 2023 and 2025, where new evidence became available, or where human rights risks accelerated. Those areas do not represent the full range of AI applications in China but are the most revealing of how the CCP is integrating AI technologies into its political control apparatus.
превод от английски Стела Джелепова, София: изд. „Лист“, 2022
Изграден като писмо на възрастен и нелечимо болен баща до неговия седемгодишен единствен син, романът „Галаад“, отличен с „Пулицър“ за 2005 г., предлага задълбочената саморефлексия на героя си и неговия фин и чувствителен философски поглед върху красотата на Творението в цялата му погрешимост и преходност, върху крехкостта на човешкия жребий, върху греховността, благодатта и смисъла. Привидно семпъл и спокоен, проникнат от мека светлина пред свършека, този плътен текст – дори и в най-битовите си ежедневни истории – излъчва едновременно метафизична лиричност и земна чувственост.
Предвид професията на разказвача Джон Еймс – конгрешански пастор в малко градче в Айова с митичното библейско име Галаад – и религиозната ерудиция на Робинсън някои читатели биха могли да хранят известни резерви или опасения към богословската страна на романа. Напразно. Разбира се, със сигурност прочитът би бил улеснен и задълбочен от познаването на тази деноминация – с корени в пуританско-калвинистката традиция, тя държи на автономията и липсата на духовни йерархии, на предопределението и личното спасение чрез благодат и вяра, на пряката връзка с Бога и т.н. С тънки нюанси Робинсън потвърждава, проблематизира или дори опровергава постулатите ѝ. Въпреки това текстът далеч не звучи богословски, а успява да превърне вечни философско-екзистенциални въпроси в четивна и универсално въздействаща проза. С изповеден тон и редица самоналагащи се библейски препратки разказвачът разгръща пред нас една уж усвоена, но и интуитивно спонтанна теология, която в крайна сметка е слята със смирението пред греховността на блудните синове, с любовта към живота и в най-ефимерните му земни проявления, с хедонистичната сладост от тактилното и признанието за прелестта на убегливото.
Проследявайки три поколения мъже от един род на пастори, Робинсън ни показва и приемствеността, и поколенческите различия у всеки от тях. Дядото, бащата и синът носят свой тип устойчивост и достойнство, при все че се отличават един от друг по базови въпроси – като проявленията на вярата, валидността на виденията и мистиката, свободата, войната, насилието в отстояването на принципите, пацифизма, прагматичността и т.н. В крайна сметка това се превръща в
роман за бащите и синовете – за (смисъла на) бащинството.
В старозаветната традиция именно бащата е този, който предава Книгата, буквата, закона, знанието на сина. В „Галаад“ се проблематизира необходимостта от оставяне на наследство – но не чрез материални завещания (всъщност това е едно от притесненията на Джон Еймс – че оставя много по-младите си жена и син без почти нищо), нито чрез назидателност и строги наставления, а чрез споделяне на цялата уязвимост на личния опит и чрез жестовете на внимание и любов (именно любовта и нежността пропиват с тона си цялото писмо).
В това писмо разказвачът – автор на стотици проповеди през живота си, се опитва да избяга от дидактизма и проповедничеството за сметка на естествените, понякога постигани в самия ход на писането житейски изводи и наблюдения. Вместо деен по мъжки сюжет и суха фактология в излагането на миналото пред момчето, бащата предлага циклично завръщане към крайъгълни събития и грижлива бдителност към мимолетни детайли и непосредствени състояния, често в преки наблюдения на детето, любимата и случващото се тук и сега. Всичко това – насред тъгата по предстоящото, което ще пропусне в израстването на сина си.
Пастор Джон Еймс има смиреното съзнание, че онова, което е прозрял и научил през живота си, може да бъде неприложимо за сина му, тъй както баща му и дядо му някога са имали своите ценностни разломи, довели до скъсването на отношенията им. Пътуването на героя с баща си като дете в търсене на гроба на изчезналия по своите дела и идеали дядо (сравнимо с онова на Аврам с Исак към планината Мория) е един от начините за постигане на (макар и посмъртно) помирение. Такова, каквото самият Джон Еймс ще търси през цялото време със своя блуден „втори“ син – наречения на него кръщелник и възможен претендент за мястото му след смъртта.
По-младият Джон Еймс Баутън се явява не само като ясно въплъщение на идеята за блудния син, но и като герой от типа на Митя Карамазов. Прозорлив за самотата и страданието на този счупен мъж, чийто живот е поредица от простъпки, пастор Еймс ще удържи своето смирение въпреки страховете и резервите. Така, както някога е разпознал яростната тъга в много по-младата си съпруга, той ще признае, че тези двама знаят много повече за непознаваемото от самия него, прекаралия десетилетия в четене. И с един финален акт ще потвърди, че Бог е милост, на която нашата греховност е безкрайно несъразмерна – че няма пречки за любовта и прошката.
Във връзка с горното почитта между родители и деца в частност и изобщо към другия е основен мотив в романа. Еймс разсъждава много за нея и за акта на благославянето (базов и в старозаветната, и в християнската традиции).
Възможно е дадено нещо да ти бъде до болка познато и същевременно да си напълно невеж за него,
признава разказвачът по въпроса за отношенията между бащи и синове, правейки уговорката, че баща му наистина е почитал баща си, въпреки неразбирането помежду им.
Опитвам се да кажа, че великата добрина и промисъл на Бога са дали на всички ни нещо, което да почитаме – на детето – родителя, на родителя – детето.
Почитта е отвъд съгласието и произтичащото от нея послушание „носи големи награди, защото в корените на истинската почит винаги е чувството за светостта на човека, който е неин обект“. А благославянето е дължимо на всичко, дори на най-низшите твари (като светулките или котетата, които някога като дете Джон Еймс е благославял в игрите си). То „може и да не усилва светостта, но я утвърждава“.
„Галаад“ е всъщност силно антропоцентричен роман, отдаващ почит на съществуването на човека тук и сега, отсам.
На онова аз, което е същност и съществително отвъд предикативността, отвъд сказуемите, били те обичам или страхувам се, или искам…
защото прелестта е тъкмо в това присъствие, оформено около „аз“ като пламък около фитил (…)
защото искам твоето скъпо тленно „аз“ да живее дълго и да обича този беден тленен свят, който все пак не мога да си представя, че няма да ми липсва жестоко.
В „Галаад“ Мерилин Робинсън изгражда и една носталгична (наред с цялoто размирие и нищета) картина на Америка между средата на XIX и средата на XX век. Америка на малките градчета, обитавани от добри и набожни хора. Историята на страната се разгръща на фона на този разказ: Американската гражданска война, аболюционисткото движение, локалните битки около въпроса за робството – т.нар. Кървав/Кървящ Канзас, които разделят дядото и бащата, Голямата депресия, сушата, бедността, продоволствената криза, испанския грип, световните войни… В малкото провинциално градче в Айова, вдигнато някога като пристан за борещите се за свобода, се разгръща и пространството на библейския Галаад, който често се споменава в писанията и чиито природни красоти, плодородие и живописност биват изтъквани.
Стараех се да изричам само истинни неща,
казва пастор Джон Еймс. И в глагола стараех се е цялото смирение на този колкото многопластов, толкова и еднозначно добър герой. Робинсън не се е опитвала да противопоставя твърде много черти в характера му – пред себе си имаме един живял дълго в самота и четене човек, чист мъж, изгубил първото си семейство и копнял десетилетия за дом, без да изгуби способността си да обича, да усеща, да вижда, да съпреживява. Да устоява на неверието около себе си дори когато сам има смелостта и интелигентността да го изучава. Да остава невинен и да вижда невинността у всеки.
Вярвам, че съществува придобита невинност, която заслужава същата почит като детската невинност.
Да, „Галаад“ е роман за придобитата невинност, за спасението чрез вярата и търсенето на благодат. И за заедността, защото „нещо, което не съществува в отношение с нещо друго, не може да се каже, че изобщо съществува“. Така, в подготовката към отвъдното, пастор Джон Еймс в крайна сметка ще създаде една апология на отсамния свят, на нашия, тленния, несъвършено съвършения, в чийто мрак се мътят чудеса. Удивителен свят, в който оставаме докрай деца:
Понякога се чувствам като дете, което веднъж отваря очите си за света и зърва удивителни неща, чиито имена никога няма да узнае, а после отново трябва да ги затвори.
Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. За нея медията „Тоест“ е отличена с Националната награда „Христо Г. Данов“ (2025) за принос в представянето на българската книга.
Рубриката е част от партньорската програма Читателски клуб „Тоест“, благодарение на която активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на включените издателства. Изборът на заглавия обаче е единствено на авторите Стефан Иванов, Севда Семер и Антония Апостолова, които биха ви препоръчали тези книги и ако имаше как да се разходите с тях в книжарницата.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
comments
