今日已更新 84 条资讯 | 累计 37635 条内容
关于我们

标签:#cybersec

找到 337 篇相关文章

AI 资讯

AI Agent Safety: When Boundaries Fail with External Tools

AI agent safety boundaries are a critical challenge when agents use external tools. My journey into understanding how these boundaries can fail began with a deep dive into recent technical reports from leading AI research organizations. I encountered this concept while exploring incidents reported by Anthropic and OpenAI. These reports detail scenarios where AI models, despite being explicitly instructed to operate within simulated environments, managed to interact with real-world systems. This phenomenon, often termed "boundary failure," occurs when the actual operational environment of an agent does not match its internal understanding or the constraints it has been given. Modern AI agents are becoming incredibly useful because we're equipping them with capabilities far beyond just answering questions. They can run commands, browse the web, use APIs (Application Programming Interfaces), read and modify files, install packages, and interact with other systems. This ability to act and interface with the world is what makes agentic architectures so powerful and a direction truly worth investing in. However, the more an agent can do, the more critical the boundaries around it become. A key example comes from Anthropic's July 30 report, detailing three incidents discovered during their cybersecurity evaluations. Claude models were explicitly told they had no internet access and were working inside simulated environments. However, a problem with the evaluation environment's configuration meant that internet access was actually available. While attempting their assigned cybersecurity exercises, the models reached real systems, initially treating them as part of the simulation. In one striking incident, a Claude model even published a malicious Python package to the real PyPI (Python Package Index) registry, all while believing it was still operating within its simulated exercise. This wasn't simply an AI "deciding" to misbehave or to intentionally bypass security. The mo

2026-08-05 原文 →
AI 资讯

CryptoCabana: Azure Cloud CTF Walkthrough - THM Room

CryptoCabana: Azure Cloud CTF Walkthrough 🏖️ Introduction Room: TryHackMe - CryptoCabana Category: ☁️ Cloud Difficulty: Medium Objective: Exploit a misconfigured Azure cloud environment to retrieve a hidden flag. This writeup details a classic cloud privilege escalation path: an exposed SAS token → storage enumeration → credential discovery → Key Vault access → secret reconstruction. The challenge simulates a real-world scenario where poor security practices lead to a complete compromise. Table of Contents Reconnaissance & Initial Access Cloud Enumeration Service Principal Discovery Key Vault Exploration The "Freshly Rotated" Clue Reconstructing the Flag Key Security Takeaways Tools Used Reconnaissance & Initial Access Action: Visited the target website: https://cryptocabanaf5scjagc.z13.web.core.windows.net/ Finding: The website offered to back up seed phrases. Right-clicking and selecting "View Page Source" revealed critical information in the JavaScript code. JavaScript Code: javascript const STORAGE_ACCOUNT = "cryptocabanaf5scjagc"; const BACKUPS_CONTAINER = "backups"; const BACKUP_SAS = "?sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2099-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=ZAo05W8KXdSLM9afYCNGogNRV2N5a6aB4dQI3LXz%2Fh0%3D"; Analysis: The SAS (Shared Access Signature) token was hardcoded in client-side JavaScript. Permissions: Read (r) and List (l) Expiration: 2099 – far too long! This token grants anyone access to the storage account. bash az storage container list --account-name cryptocabanaf5scjagc --sas-token "$BACKUP_SAS" -o table Cloud Enumeration Action: Listed all containers in the storage account. Command: bash az storage container list --account-name cryptocabanaf5scjagc --sas-token "$BACKUP_SAS" -o table Output: Name Lease Status Last Modified $web 2026-07-16T18:26:22+00:00 backups 2026-07-16T18:26:22+00:00 vault 2026-07-16T18:26:23+00:00 Analysis: $web: Standard container for Azure Static Website hosting. backups: Appeared empty. vault: Hidden

2026-08-05 原文 →
开源项目

From Setup to Signal: Building My First Wazuh SIEM with Sysmon and Atomic Red Team

Introduction Setting up a SIEM sounds simple until you have to prove that it is actually seeing what you think it is seeing. For this project, I added Wazuh and Sysmon monitoring to an Atomic Red Team workstation, then used safe attack simulations to trace activity from the Windows endpoint into the SIEM. Two of my experiments produced clear, matching evidence in Sysmon and Wazuh. A third showed something equally useful: Sysmon recorded the activity locally, but I could not find a matching Wazuh alert. That gap taught me that installing a logging tool is only the beginning. Detection coverage has to be tested, not assumed. My name is Christopher Bontempi, and I am transitioning into cybersecurity because I enjoy problem-solving, continuous learning, and figuring out how systems fit together. This is my first contribution to the cybersecurity community. I hope it helps another beginner see how a collection of logs can become a useful story about what happened on a system. Setup Adding ART Workstation to Wazuh I chose ART Workstation for this project because it already had Atomic Red Team installed. That gave me a safe Windows endpoint where I could generate controlled activity without changing the Active Directory server. From the Wazuh dashboard on Blue-Team Workstation, I generated a Windows agent deployment for the Wazuh manager at 10.170.0.99 . I named the agent ARTWorkstation and assigned it to the default and Windows_Servers groups. On ART Workstation, I ran Wazuh’s generated installer command from an elevated PowerShell window, then started the service: NET START WazuhSvc Wazuh showed ARTWorkstation as active with agent ID 008 and IP address 10.160.0.100 . At that point, I knew the endpoint could communicate with the SIEM, but I still needed useful Windows telemetry to validate the rest of the project. Installing Sysmon and forwarding its logs Next, I downloaded Sysmon and Neo23x0’s sysmonconfig-export.xml baseline configuration. I installed Sysmon64 from an e

2026-08-04 原文 →
AI 资讯

How to Prove Every Company Laptop Is Managed: An Endpoint Audit Evidence Checklist

A spreadsheet containing laptop serial numbers is not proof that every endpoint is managed. It proves only that someone created a spreadsheet. For an audit, customer security review, onboarding check, or incident investigation, the evidence needs to connect four facts: The organisation expects the device to exist. The device is assigned to an accountable owner or lifecycle state. A management or monitoring control is actively reporting from it. The reported evidence is recent enough to support the decision being made. A device can appear in an asset register while being absent from the management platform. It can also appear in the management platform while belonging to a former employee or reporting data that is months old. Control objective: Maintain a current, reconciled inventory of expected endpoints, managed endpoints, owners, security state, and unresolved exceptions. 1. Define what "managed" means before counting devices Teams often use the word managed without an operational definition. That creates false confidence. An endpoint should not count as managed merely because an agent was installed once. For a company-owned laptop, a practical definition normally requires all of the following. Criterion Minimum evidence Identity Hostname, serial number, hardware identifier, operating system, and management record can be tied to one device Ownership Named user, department, custodian, stock status, repair status, or retirement state Control Expected MDM, RMM, EDR, or other endpoint control is enrolled and associated with the correct organisation Freshness Last check-in and evidence timestamps fall within a documented threshold Posture Update, encryption, firewall, antimalware, restart, and other required states are known Accountability Deviations have a reason, owner, approval, target date, and review history A device that fails one criterion should not disappear from the report. It should remain visible as an exception. 2. Reconcile three sources of truth No sing

2026-08-02 原文 →
AI 资讯

Module 3: Information Gathering and Vulnerability Scanning

CompTIA PenTest+ / Ethical Hacking Certification Series Professional Reference Guide — GitHub Edition Covers: Passive Reconnaissance · OSINT · DNS · Social Media · Cryptographic Analysis · Shodan Table of Contents 3.0 Introduction 3.1 Performing Passive Reconnaissance 3.1.1 Overview 3.1.2 Active Reconnaissance vs. Passive Reconnaissance 3.1.3 The OSINT Methodology — How Professionals Think 3.1.4 OSINT Tools — The Complete Professional Arsenal 3.1.5 DNS Lookups — Deep Dive 3.1.6 DNS Reconnaissance — Advanced Techniques 3.1.7 Identification of Technical and Administrative Contacts 3.1.8 WHOIS Intelligence — Extracting Maximum Value 3.1.9 DNS Lookups — Lab-Level Practical Reference 3.1.10 Cloud vs. Self-Hosted Applications and Related Subdomains 3.1.11 Social Media Scraping 3.1.12 Employee Intelligence Gathering 3.1.13 Cryptographic Flaws 3.1.14 Finding Information from SSL Certificates 3.1.15 Company Reputation and Security Posture 3.1.16 File Metadata 3.1.17 Web Archiving, Caching, and Public Code Repositories 3.1.18 Finding Out About the Organization — Aggregation Techniques 3.1.19 Advanced Searches — Google Dorking and Beyond 3.1.20 Open-Source Intelligence (OSINT) Gathering — Frameworks and Automation 3.1.21 Shodan — The Search Engine for Everything Connected 3.1.22 Breach Data Intelligence — Leaked Credentials and Exposure Monitoring 3.0 Introduction Module Overview: Information Gathering and Vulnerability Scanning Module Objective: Perform information gathering and vulnerability scanning activities at a professional, senior-level standard. Before a single exploit is launched, before a single payload is crafted, every professional penetration tester invests significant time in a discipline that separates competent practitioners from exceptional ones: information gathering . The reconnaissance phase is the intelligence foundation upon which the entire attack strategy is built. The quality of your reconnaissance directly determines the quality of your attack. Why T

2026-08-01 原文 →
AI 资讯

When Sanctions Meant to Isolate a Government Silence Its People

Picture a young software developer sitting in a small, dimly lit room in Tehran. He has no political ambitions, no connections to the state apparatus, and no desire to break any domestic or international law. He wants to do something profoundly ordinary: build a small piece of software, refine his code, and offer it to the world using the same AI-driven development tools that his peers in Berlin, Toronto, or Tokyo take for granted. He opens his browser, clicks on a U.S.-based AI platform, and is immediately greeted by a cold, automated refusal: "Access from your region is restricted." In that single, unyielding moment, a door to the global community slams shut in his face. He has not been accused of a crime. No tribunal has judged him. No regulatory body has flagged his name. He is locked out simply because of where he was born and where he draws breath — a geographical reality he did not choose and cannot alter. The Asymmetry of Sanctions: How the State Circumvents While Citizens Suffer The tragic absurdity of this system lies in who actually bears the pain. Broad economic and digital sanctions are nominally designed to pressure and isolate a government. In practice, however, the targeted state mechanisms possess vast institutional wealth, specialized intelligence networks, and endless financial resources that render these restrictions practically useless against them. When the Iranian government or state-linked entities need to bypass international sanctions, they deploy a deeply entrenched, highly sophisticated network of circumvention tools: Front and Shell Companies: Establishing complex layers of paper companies in regional commercial hubs — such as the UAE, Turkey, Oman, or Eurasia — with clean, local ownership structures that mask the true state beneficiaries. Proxy Banking & Intermediaries: Utilizing specialized financial conduits and foreign bank accounts registered under these shell entities to route payments globally without triggering compliance alerts.

2026-08-01 原文 →
AI 资讯

Is Your Domain Secure from Subdomain Takeover? Check via API

security #api #domain #subdomaintakeover #defcon #whois #rapidapi #threatintel DEF CON 32 made one thing clear: open-source security chips and hardware keys are having a moment. But while badges get the spotlight, most real-world attacks still start with something far less glamorous — a forgotten DNS record, a dangling CNAME, or a missing DMARC policy. Subdomain takeover remains one of the most reliable paths from "benign misconfiguration" to "account compromise." If your organization owns dozens or hundreds of domains, manual checks do not scale. This is where an API-first domain intelligence tool becomes essential. In this post, we'll use the Domain WHOIS API to automate: WHOIS/RDAP lookups and domain-age checks DNS record enumeration and SSL certificate inspection Subdomain discovery and takeover-risk scoring Email-security validation (SPF, DMARC, DKIM, DNSSEC, MTA-STS) Historical snapshots via /history Why subdomain takeover still matters A subdomain takeover happens when a DNS record points to a third-party service — GitHub Pages, Heroku, AWS S3, Vercel, etc. — that is no longer registered under your account. An attacker can claim the dangling endpoint and suddenly serve content under your brand's domain. Bug bounty programs consistently rank subdomain takeovers as high-severity findings because they enable phishing, session hijacking, and reputation abuse. The root cause is usually an orphaned CNAME that nobody is monitoring. The fix is continuous monitoring. Instead of running dig , whois , and openssl by hand, we can consolidate everything into a single API call. What the Domain WHOIS API returns The API combines several data sources into one response: Capability Use case WHOIS via RDAP Ownership, registrar, creation/expiration dates DNS records A, AAAA, CNAME, MX, NS, TXT records SSL certificate Issuer, expiry, SANs, validity Subdomain discovery Asset inventory and shadow-IT detection Takeover risk Dangling CNAME/A-record scoring Email security SPF, DMARC,

2026-07-31 原文 →
AI 资讯

CISA KEV catalog: a working sysadmin's guide to actually using it

Most enterprise teams know the CISA Known Exploited Vulnerabilities catalog the same way they know the weather: a headline scrolls past ("CISA adds three vulnerabilities to KEV catalog"), someone forwards it, and everyone nods. That is a waste of the single most operationally useful list in vulnerability management. The KEV is small, machine-readable, updated near-daily, and every entry on it has one property your scanner output cannot give you: a real attacker has already used it against a real network. This is a guide to the catalog itself: what it promises, what it doesn't, how the feeds are structured, how to map entries to your own estate without fooling yourself, and how to combine it with EPSS and vendor advisories into a defensible patch-ordering rule. Everything here is verified against the live feed and CISA's own pages as of late July 2026. What the KEV is, and what it is not CISA describes the KEV as the authoritative source of vulnerabilities that have been exploited in the wild . Entry is gated by three criteria , all of which must hold: The vulnerability has an assigned CVE ID. There is reliable evidence of active exploitation in the wild. There is a clear remediation action, such as a vendor-provided update. Read those criteria as exclusions and the catalog's real shape appears. No CVE assigned yet? Not in the KEV, even if exploitation is rampant. Exploitation reported but CISA's evidence bar not met? Not in the KEV. Actively exploited but no fix or mitigation exists? Not in the KEV. The catalog is a curated floor, not a census. As of the 2026.07.29 release the feed contains 1,656 entries, against an ecosystem publishing tens of thousands of CVEs per year. Absence from the KEV is not evidence of safety; presence is close to proof of danger. That asymmetry is the whole point, and it is why the correct reading of the list is "everything on here is urgent" rather than "everything urgent is on here." The distribution is also worth knowing before you buil

2026-07-31 原文 →