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

标签:#cybersecurity

找到 365 篇相关文章

AI 资讯

Adapting Ghidra for Reverse Engineering Undocumented Binary Architectures

1. Language Architecture in Ghidra When Ghidra loads an architecture (such as the MOS 6502), it parses the .ldefs manifest file, which declares metadata and binds three foundational specification pillars: The .pspec (Processor Specification): Defines the processor’s hardware context. It declares special-purpose registers (e.g., stack pointer SP , status/flags registers), default memory maps (RAM, ROM, I/O), and hardware interrupt vectors. The .cspec (Compiler Specification): Defines the ABI and calling conventions (e.g., parameter passing mechanisms), stack alignment rules, and return value handling. This is the critical building block enabling the decompiler to reconstruct assembly into readable C code. The .sla / .slaspec (SLEIGH Specification): .slaspec : The human-readable source file describing the instruction set architecture (opcodes, instruction formats, and p-code semantics). .sinc (SLEIGH Include): Modular inclusion files (typically used to split complex architectures like ARM or x86, or isolate instruction subsets like Thumb). Given the simplicity of the 6502, everything is defined directly within the .slaspec file. .sla : The compiled binary version of the .slaspec (generated by the Sleigh compiler). Ghidra loads this compiled .sla file into memory at runtime for optimal performance. 2. The Challenges of Reverse Engineering Undocumented Binaries When dealing with a binary compiled for an undocumented processor, Ghidra's default paradigm faces major limitations: The .slaspec file is unavailable. Ghidra attempts to aggressively disassemble everything. Analyzing an undocumented target requires a strict two-phase approach. 3. Missing .slaspec File Without a valid .slaspec definition, Ghidra renders ?? for every opcode. The primary objective when tackling an unknown CPU is precisely to reconstruct this missing .slaspec specification. 4. Overcoming Ghidra's Aggressive Disassembly By default, Ghidra (like most disassemblers) employs an exhaustive strategy (usin

2026-08-07 原文 →
AI 资讯

I Did 52 WHOIS Lookups On Attackers — Here's What I Learned

security #api #webdev #discuss The chat went live at 2 PM. By 2:14 it was a war zone. I thought adding real-time chat to my dev blog would spark pair-programming threads. Instead, bots flooded it with phishing links and slurs. One bot even dropped an oddly specific threat about my home city. I flipped on request logging. In the next 24 hours it logged 52 distinct attacker hostnames. IP bans did nothing. They came back from new IPs, new ASNs, new registrars. IP bans felt like swatting flies. I wanted to know what these domains actually were. That's when I started bulk-WHOISing every domain they posted. What 52 hostile domains actually look like I wrote a small Python runner. Feed it a list of hostnames and it spits out JSON. The first version used public RDAP servers directly. Public RDAP servers were slow, rate-limited, and ccTLDs broke them. I wanted DNS, SSL, subdomains, email history, and takeover risk in the same response. I landed on the enrichment endpoint at RapidAPI and put the script on GitHub . import json , time , sys , os from urllib.parse import quote import requests RAPIDAPI_KEY = os . environ . get ( " RAPIDAPI_KEY " , "" ) BASE_URL = " https://domain-whois2.p.rapidapi.com/whois " HEADERS = { " X-RapidAPI-Key " : RAPIDAPI_KEY , " X-RapidAPI-Host " : " domain-whois2.p.rapidapi.com " } def lookup ( domain : str ): url = f " { BASE_URL } ?domain= { quote ( domain ) } " try : r = requests . get ( url , headers = HEADERS , timeout = 20 ) r . raise_for_status () return r . json () except requests . exceptions . Timeout : return { " domain " : domain , " error " : " timeout " } except requests . exceptions . HTTPError as e : return { " domain " : domain , " error " : f " http { e . response . status_code } " } except Exception as e : return { " domain " : domain , " error " : str ( e )} def batch ( domains , delay = 0.6 ): results = [] for d in domains : print ( f " [*] { d } " , file = sys . stderr ) results . append ( lookup ( d )) time . sleep ( delay ) r

2026-08-06 原文 →
AI 资讯

Cybersecurity Meets Patient Safety: Building an ECG STRIDE Threat Model

* *The purpose of this light version threat model is to demonstrate how STRIDE can be applied to an ECG device. It is intended for readers learning system decomposition and threat modelling techniques. The example includes a simplified set of components, threats, and mitigations for educational purposes and is not intended to represent a comprehensive medical device cybersecurity assessment or any regulatory submission. **Assumption: This example models a typical ECG device, which may include network connectivity in a clinical environment. Trust Boundaries: Trust boundaries exist between the ECG device, hospital network, and external clinical systems. System Definition: ECG is the abbreviation for an Electrocardiogram. It is used to detect electrical activity of the heartbeat in the form of P wave, QRS complex and T wave to identify and diagnose irregularities in heartbeat. Electrodes are placed on patient’s limbs and chest to measure the electrical potentials. It translates tiny electrical signals into digital wave patterns. These waveforms are used by the doctors to evaluate the heart rhythm and check for cardiac damage. Components • Electrodes • Lead wires • Amplifier and filters • Analogue-to-Digital Converter (ADC) • Main processing unit • Display/printer • Local storage • Network interface (Ethernet/Wi-Fi/Bluetooth), if supported. Data Flow Diagram: Electrodes → Lead wires → Amplifier and filters → Analogue-to-Digital Converter (ADC) → Main processing unit → Display / Printer / Local storage / Network interface (if supported) |TRUST BOUNDARY|→ Electronic Health Record (EHR) / Clinical Information System 2. STRIDE Threats: Threats Description Spoofing in general ** - Spoofing is the act of impersonating a legitimate user, device, or system to gain unauthorized access to resources or services. Violates authentication. * Spoofing in ECG * - An attacker may impersonate an authorized clinician, connected medical device, or trusted clinical system to gain unauthoriz

2026-08-06 原文 →
AI 资讯

Passwords Are Losing, and the Numbers Finally Prove It

What the report found The FIDO Alliance — the industry group behind the passwordless authentication standard — released its State of Passkeys 2026 report in May, based on research across 11,000 consumers and 1,400 enterprise decision-makers in ten countries. A few numbers stand out: passkeys now see a 93% sign-in success rate compared to 63% for passwords, and average sign-in time drops to roughly 8.5 seconds versus over 30 seconds for password-based logins. Awareness has also jumped to 90% of consumers, with about 5 billion passkeys now active worldwide. The security case is the more important one. Passkeys are built to be phishing-resistant by design — unlike a password, there’s no shared secret that can be typed into a fake login page, because the credential is cryptographically tied to the real site and your device. That’s a structural fix, not a behavioral one — it doesn’t depend on you spotting a scam email, which is precisely where most password-based breaches start. Why adoption still lags Here’s the more interesting number: even among organizations that have rolled out passkeys, the majority still keep passwords running in parallel as a fallback, and a large share of individual users still don’t use passkeys everywhere they’re offered. The barrier at this point isn’t awareness — it’s habit. People default to what’s familiar, even when the safer option is one tap away. The practical takeaway Most major platforms — Google, Apple, Microsoft, and a growing list of banks and retailers — now offer passkeys as a login option, usually sitting quietly in account security settings labeled “passkey” or “sign in without a password.” The action worth taking today: pick your two or three most important accounts (email first, since it’s the recovery path to everything else) and set up a passkey where it’s offered, instead of waiting for a breach to force the decision. Passkeys aren’t foolproof — device loss and account-recovery flows are still an active area of security r

2026-08-06 原文 →
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 原文 →