标签：#infosec

If you have ever logged into a corporate computer, searched for a colleague in your company’s email directory, or used a single set of credentials to access dozens of different internal applications, you have likely interacted with LDAP . Standing for Lightweight Directory Access Protocol , LDAP is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an IP network. In simpler terms, it is the underlying language that allows different systems and applications to communicate with a central directory to find information about users, devices, and permissions. Think of LDAP as a highly organized, digital phonebook. When an application needs to know if "John Doe" is a valid user and what his password is, it uses LDAP to ask the phonebook. How LDAP Organizes Data Unlike traditional relational databases (like SQL) that store data in tables, LDAP stores data in a hierarchical, tree-like structure known as the Directory Information Tree (DIT) . This makes it incredibly fast at reading and searching for information, which is exactly what an authentication system needs to do millions of times a day. Here are the core components of this structure: Root: The top level of the directory tree, usually representing the organization (e.g., dc=example, dc=com ). Branches (Organizational Units - OU): Categories or departments within the organization (e.g., ou=Marketing , ou=Servers ). Leaves (Entries): The actual objects being stored, such as a specific user, printer, or computer. Attributes: The specific pieces of data tied to an entry. For a user entry, attributes might include givenName (first name), mail (email address), and userPassword . Every entry in an LDAP directory has a unique identifier called a Distinguished Name (DN) . It acts like an absolute file path. For example, John Doe’s DN might look like this: cn=John Doe, ou=Marketing, dc=example, dc=com How Applications Talk to LDAP When an

Understanding DMARC and the 'p=none' Policy DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489, is an email authentication protocol. It builds upon SPF (Sender Policy Framework, RFC 7208) and DKIM (DomainKeys Identified Mail, RFC 6376) to provide domain owners with greater control. DMARC instructs recipient mail servers on how to handle emails that fail authentication and provides reporting on these failures. The p=none policy is often adopted as a preliminary step in DMARC implementation. It instructs recipient servers to take no specific action on emails failing DMARC alignment. Its primary function is to enable the collection of aggregate and forensic reports without impacting email deliverability. Many organizations view p=none as a safe, non-disruptive way to begin their DMARC journey. This initial perception, however, overlooks critical security implications. While it offers visibility, p=none provides no actual enforcement against malicious email. The Critical Security Vulnerability of p=none The fundamental flaw of DMARC p=none lies in its complete lack of enforcement. When a DMARC record is set to p=none , recipient mail servers will not block, quarantine, or reject messages that fail DMARC authentication. This includes emails that spoof your domain directly. Threat actors exploit this vulnerability to conduct phishing, business email compromise (BEC), and brand impersonation attacks. They can send emails appearing to originate from your legitimate domain, knowing that p=none offers no protective barrier. The recipient mail server simply delivers the fraudulent message. This policy effectively leaves your domain unprotected against direct domain spoofing. Despite having a DMARC record, your organization remains susceptible to advanced phishing techniques. The security posture of your email ecosystem is compromised. The Illusion of Insight: Data Without Action DMARC p=none does provide valuable data through its repor

Most developers think password hashing is about authentication. It's not. Authentication is just a side effect. Password hashing exists for a much darker reason: because databases get stolen. Every year, companies invest millions in firewalls, monitoring systems, cloud security, and access controls. Yet breach after breach continues to make headlines. The uncomfortable truth is that security teams don't assume a breach will never happen. They assume it eventually will. And when that day comes, one question determines whether the incident becomes a minor security event or a full-scale disaster: Did you hash the passwords? The Difference Between an Incident and a Catastrophe Imagine an attacker gains read access to your production database. Not a far-fetched scenario. A leaked backup. A vulnerable API. A compromised employee account. A misconfigured cloud bucket. The attacker runs a simple query: SELECT email , password FROM users ; If your system stores passwords in plain text, the breach is over. The attacker already won. No advanced techniques. No brute force. No expensive infrastructure. They now possess something more valuable than your database itself: your users' digital identities. Because users rarely reuse databases. They reuse passwords. The same password protecting an account on your platform might also unlock their Gmail, GitHub, LinkedIn, banking app, or company VPN. What started as your security problem instantly becomes everyone else's. This Is Not Theoretical History has repeatedly shown what happens when passwords are handled incorrectly. The RockYou breach exposed more than 30 million passwords stored in plain text. Attackers didn't need to crack anything. They simply read the data. Years later, those leaked passwords were still appearing in credential stuffing attacks across the internet. A single backend decision survived longer than the company itself. That's the thing about password leaks. They don't expire when the incident report is published.

For security reasons, we consider "Target app", as the target we practiced on, and the real name won't be disclosed in this post. The target app, was a niche music streaming platform, available in web and mobile PWA, meaning the structure is same but access is easier for cross platform. The app worked in this way : You register using an account, 3rd party like google or via email After that you can use the app for free with a 3 day window (3 day trial) After the 3 day you gotta buy subscription to continue listening The flaw, existed in the first step, when you register using an email, no verification happens! You could enter any type of string@something.com , a random password and start your free trial. So what happens is that first I use string1@something.com , for 3 days. When the time runs out, I use string2@something.com for another 3 days. And since the app's trial and actual subscription don't have any difference, and the 3 day time window is the only limitation, the user with such knowledge from the app doesn't need to buy any subscriptions while such flaw exists! Mitigation : Apply email verification step after user input, so they have to use the received link to verify their address Blacklist "temporary email" service's address or IPs, so users won't generate any email to register after their trial has expired. This way, the registration process isn't too complex while keeps app from attackers avoiding a "For ever free" usage on the app.

TL;DR what: Three chained vulnerabilities in LiteLLM AI gateway allow default low-privilege users to bypass authorization, escalate to admin, and execute arbitrary code on the server. impact: Full compromise exposes every provider API key (OpenAI, Anthropic, Azure, etc.), database credentials, decryption secrets, and all prompts and responses passing through the gateway. fix: Upgrade immediately to LiteLLM v1.83.14-stable or later, which includes complete fixes for CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217. who: Any organization running LiteLLM proxy to broker AI model access, especially those with internal users or agents routing through the gateway. A critical vulnerability chain in LiteLLM, a widely deployed open-source AI gateway, allows attackers starting from a default low-privilege account to achieve full server takeover and code execution. Obsidian Security researchers disclosed the three-bug chain rated CVSS 9.9, with maintainer BerriAI shipping complete fixes in version 1.83.14-stable on May 2, 2026. LiteLLM brokers API calls to more than 100 AI model providers—OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, and others—behind a single OpenAI-compatible interface. Organizations deploy it as a central gateway to manage costs, enforce policies, and route requests across multiple backends. That centralized position makes it a high-value target: a compromised proxy exposes every provider key it holds, the secrets that decrypt stored credentials, and every prompt and response flowing through it. The Three-Link Chain The attack begins with CVE-2026-47101, an authorization bypass. When a regular internal_user creates a virtual API key, LiteLLM stores the caller-supplied allowed_routes field without validating it against the user's role. This field is intended to restrict what the key can access, but the proxy also treats it as a fallback authorization grant. An attacker can mint a key with allowed_routes: ["/*"], a wildcard that opens every r

Cross-border purchasing platforms commonly use marketing tactics such as coupons, registration points, order rebates, and spend-based discounts to acquire new users and boost engagement. However, public promotions are prime targets for “wool hunters” (fraudsters) who exploit batch account registration, fake orders, malicious order spamming, and combined discount abuse to drain platform benefits, causing direct financial losses. Most purchasing systems lack dedicated event risk controls, making them highly vulnerable to batch exploitation as soon as a promotion goes live. This not only leads to financial losses but also crowds out genuine user benefits and distorts campaign effectiveness. This article details Taocarts’ comprehensive anti-fraud risk control framework, which uses multi‑dimensional behavior detection, rule‑based blocking, and account risk assessment to accurately distinguish real users from malicious exploiters, ensuring fair and controllable marketing activities. First, we identify common malicious exploitation scenarios and system vulnerabilities in cross‑border platforms: Batch account registration – Using new‑user exclusive coupons and registration points to harvest benefits repeatedly. Fake order placement and cancellation – Repeatedly claiming limited‑time discounts or rebates by placing and then canceling orders. Multiple accounts from the same device/IP – Spamming orders to consume activity quotas. Illegal discount stacking – Violating platform rules by combining multiple coupons or point deductions. Activity volume manipulation – Generating fake orders to earn activity rewards or points, creating false engagement data. Traditional systems have no risk rules and cannot detect batch operations or abnormal behavior, leading to wasted marketing spend and campaigns that actually lose money. Taocarts builds a fine‑grained anti‑exploit rule engine based on four dimensions: user behavior, device information, network characteristics, and order data, ena

Imagine you lose your work laptop on a commute. It holds 3 years of customer PII, internal product roadmaps, and access keys to your company's cloud infrastructure. Without full disk encryption enabled, anyone who finds the device can access every file in 10 minutes or less with a free bootable USB tool. With encryption enabled? They'll never access your data, even if they brute-force the password for decades. Per IBM's 2025 Cost of a Data Breach Report, organizations that use encryption save significantly on breach costs compared to teams that skip encryption. As cyber threats grow more sophisticated, and quantum computing edges closer to breaking legacy cryptographic standards, encryption is no longer an optional add-on—it's a core requirement for every digital system. This guide breaks down everything you need to know about data encryption, from core concepts to 2026's latest post-quantum developments, with actionable best practices for teams of all sizes. Table of Contents Core Concepts of Data Encryption How Does Data Encryption Work? Key Data Encryption Algorithms (2026 Approved & Deprecated) Encryption for All 3 Data States: At Rest, In Transit, In Use Real-World Data Encryption Use Cases Encryption Standards & Compliance Regulations Data Encryption Best Practices Common Encryption Mistakes to Avoid 2024-2026 Encryption Trends & Future Developments Conclusion & Key Takeaways References Core Concepts of Data Encryption Data encryption is a cryptographic process that converts human-readable plaintext into unreadable scrambled ciphertext using mathematical algorithms and secret keys. Only authorized parties with the correct decryption key can reverse the process to recover the original plaintext. Core Benefits of Encryption Encryption provides three non-negotiable security properties: Confidentiality : Only authorized users can access sensitive data Authentication : Verifies the origin of encrypted data Integrity : Confirms encrypted data has not been tampered w

Every detection vendor ships a MITRE ATT&CK heatmap, and every one of them is mostly green. Broad coverage, techniques lit up across the board, a reassuring wall of color in the sales deck and the board slide. It's the universal flex. We cover the matrix. Then you parse the actual rules – the real YAML in the public repo, not the marketing layer on top of it – and the green collapses into three tactics. Everyone covers execution and persistence. Almost nobody covers discovery, lateral movement, or collection. The heatmap wasn't measuring coverage. It was counting rules, and counting them in a way designed to look complete. What a green cell actually means A green cell in a Navigator layer means one thing: at least one rule somewhere references that technique tag. That's it. Not "we detect this reliably." Not "this fires on real attacks and stays quiet otherwise." Not "this survives an attacker who knows the rule exists." One rule that names the technique in its metadata turns the cell green, and forty rules turn it the same shade. Unless the layer is scored by rule count – and most published heatmaps aren't – one and forty are indistinguishable. I've written before that an untested detection isn't a detection, it's a query that runs on a schedule. The heatmap is the same lie one level up. A green matrix isn't coverage. It's a wall of queries that run, rendered in a color that means "present," dressed up as a color that means "protected." The vendor knows the difference. The buyer staring at the green doesn't. You can measure the real shape yourself Here's the part the heatmap marketing depends on you not doing: the rules are public, and you can count them. SigmaHQ, Elastic's detection-rules, Splunk ESCU, Panther, Sublime – all on GitHub, all tagged with attack.TXXXX technique IDs and tactic tags in the rule metadata. The method is boring on purpose. Walk the rule directories. Pull the ATT&CK tags out of each rule. Aggregate by technique, roll the technique counts up

From the motivation-pattern-log — a public, dated, falsifiable prediction log for AI-era cybersecurity attack patterns grounded in motivation analysis. Predictions are scored quarterly against stated falsifiers. PREDICTION-20260601-0008 Created: 2026-06-01 Pattern: boredom-with-asymmetric-leverage Substrate: Open-source package registries (npm, PyPI, Crates.io, Packagist) and GitHub Actions CI/CD workflow injection Leading indicator observed: Four distinct, concurrent, cross-registry supply chain campaigns (TrapDoor: 34 packages across npm/PyPI/Crates.io; Megalodon: 5,718 automated commits to 5,561 GitHub repos in six hours; Packagist compromise of 8 packages; Laravel-Lang PHP credential stealer) appeared within a 72-hour window in 2026-W22, all exhibiting automation signatures — throwaway publisher accounts, wave publishing, base64-encoded shell payloads, off-the-shelf delivery via GitHub Releases — consistent with toolkit operation rather than bespoke tradecraft. npm's reactive rollout of 2FA-gated publishing signals registry operators recognizing volume pressure. Predicted window: 2026-Q3 through 2027-Q1 Predicted shape: Automated, low-sophistication credential-stealing and backdoor-planting campaigns against npm, PyPI, Crates.io, and Packagist will continue to increase in incident volume while average per-campaign novelty declines. The dominant operational signature will be scripted account creation, automated package publication across multiple registries simultaneously, and CI/CD workflow injection via forged or compromised GitHub bot identities — all executable with commodity toolkits requiring no original exploit development. At least two registry operators beyond npm will announce reactive publishing controls (mandatory 2FA, namespace-squatting detection, automated malware scanning with publication holds) within the window in direct response to volume pressure. Security vendors will report a measurable increase in "unsophisticated supply chain" incidents re

The Transition A few years ago, bug hunting was a manual craft. You scanned subdomains with one tool, tested endpoints with another, and stitched results together by hand. Today, AI changes the speed entirely. Not by replacing the hunter. By eliminating the boring parts. What AI Actually Changes 1. Reconnaissance at Scale Subdomain enumeration, port scanning, and technology fingerprinting used to take hours. AI-powered pipelines now do this in minutes: Passive reconnaissance via Certificate Transparency logs, search engines, and DNS records Automated crawling and endpoint discovery Technology stack detection from response headers and HTML patterns JavaScript file analysis for hidden endpoints and API keys The machine does the grunt work. The human interprets the results. 2. Pattern Recognition Vulnerability classes have signatures. SQL injection looks different from XSS, which looks different from SSRF. AI models trained on thousands of real vulnerabilities can flag suspicious patterns faster than manual code review. This is not about finding zero-days. It is about catching the low-hanging fruit that everyone else misses because they are in a hurry. 3. Intelligent Fuzzing Traditional fuzzers throw random data at endpoints and wait for crashes. AI-guided fuzzers understand the input format and generate test cases that explore edge cases a human would not think of. The result: fewer requests, better coverage, higher signal-to-noise ratio. Where AI Struggles Business Logic Flaws AI does not understand your application's purpose. It cannot tell if a discount code is applied twice, or if a user can access another user's private data through a convoluted API flow. These are the vulnerabilities that require context. Human context. Authentication Logic Authentication bypasses are often creative. They exploit the gap between what the developer intended and what the code actually enforces. AI can find simple auth flaws, but multi-step authentication bypass chains still need h