Author/Presenter: Andrea M. Matwyshyn
Our sincere appreciation to BSidesLV, and the Presenters/Authors for publishing their erudite Security BSidesLV24 content. Originating from the conference’s events located at the Tuscany Suites & Casino; and via the organizations YouTube channel.
The post BSidesLV24 – IATC – Difficult Conversations appeared first on Security Boulevard.
Track, measure, and prove your AppSec impact with the Mend.io Value Dashboard.
The post Introducing the Mend.io Value Dashboard: Measure and Showcase Your Security Impact appeared first on Security Boulevard.
via the respected Software Engineering expertise of Mikkel Noe-Nygaard and the lauded Software Engineering / Enterprise Agile Coaching work of Luxshan Ratnaravi at Comic Agilé!
The post Comic Agilé – Luxshan Ratnaravi, Mikkel Noe-Nygaard – #330 — AI For Job Hunting appeared first on Security Boulevard.
Recently, two critical security flaws were discovered in Kentico Xperience 13, a popular digital experience platform (CMS). Tracked as CVE-2025-2746 and CVE-2025-2747, these vulnerabilities allow unauthenticated attackers to bypass the Staging Sync Server’s authentication, potentially gaining administrative control over the CMS. Both issues carry a CVSS score of 9.8 (Critical) (Warning: Multiple Critical & High...
The post Exploited! Kentico Xperience Staging Service Authentication Bypass Vulnerabilities (CVE-2025-2746 & CVE-2025-2747) appeared first on IONIX.
The post Exploited! Kentico Xperience Staging Service Authentication Bypass Vulnerabilities (CVE-2025-2746 & CVE-2025-2747) appeared first on Security Boulevard.
Authors/Presenters: Sick.Codes, Casey John Ellis
Our sincere appreciation to BSidesLV, and the Presenters/Authors for publishing their erudite Security BSidesLV24 content. Originating from the conference’s events located at the Tuscany Suites & Casino; and via the organizations YouTube channel.
The post BSidesLV24 – IATC – Hungry, Hungry Hackers appeared first on Security Boulevard.
Canada's digital infrastructure relies heavily on APIs, facilitating a range of services from citizen interactions to vital government data exchanges. This interconnectedness, though revolutionary, brings forth intricate security challenges. Comprehending and complying with the Government of Canada's API standards is now imperative rather than optional. We will delve into these standards, the increasing threat landscape, and examine how solutions like Salt Security can protect your APIs.
Understanding the API Standards Set by the Government of Canada:The Digital Standards from the Government of Canada provide a well-defined framework for public sector API development. These standards highlight crucial elements that ensure APIs are effective, secure, and sustainable:
These guidelines are essential for efficient government service delivery, concentrating on lifecycle management and optimizing performance.
The Importance of API Security in Canada:Canadian government APIs are often responsible for handling sensitive citizen data, making them attractive targets for cyber threats. Non-compliance with government standards and security best practices can lead to severe consequences, including:
Thus, protecting these key interfaces is crucial for safeguarding citizen information and ensuring operational reliability.
Essential API Security Considerations for Canadian Organizations:Organizations in Canada should embrace a layered security approach. This strategy includes strong authentication and authorization, data encryption, and thorough input validation to ward off attacks. Ongoing monitoring and logging of API traffic are essential for detecting anomalies and responding to issues. Additionally, regular vulnerability assessments and timely patches are critical. Incorporating security at every stage of the API lifecycle, as advocated by the "Security First" principle, is vital.
How Salt Security Safeguards Canadian APIs:Salt Security provides a tailored solution that aligns with the Canadian government's Digital Standards. By offering comprehensive visibility and proactive security measures, Salt Security aids organizations in maintaining compliance and safeguarding sensitive data. The key features, along with their direct correlations to Canadian regulations, include:
Automated API Discovery:Securing APIs is an essential responsibility for Canadian organizations, especially in government. By understanding and complying with the Digital Standards of the Government of Canada and employing cutting-edge API security solutions like Salt Security, organizations can safeguard sensitive data, maintain public trust, and support critical digital services.
If you want to learn more about Salt and how we can help you on your API Security journey through discovery, posture governance, and run-time threat protection, please contact us, schedule a demo, or check out our website.
The post Securing Canada’s Digital Backbone: Navigating API Compliance appeared first on Security Boulevard.
AI is now part of the botnet. See how it’s powering ATOs and fake accounts, and why real-time, multi-layered detection is the only way to fight back.
The post How AI is Fueling ATOs & Fake Account Creation—And Why Bot Detection Needs to Evolve appeared first on Security Boulevard.
The new SonarQube Server 2025 Release 2 contains significant enhancements across code quality, code security, and issue remediation with AI CodeFix. Read on to learn more about these great new capabilities.
The post SonarQube Server 2025 Release 2 Announcement appeared first on Security Boulevard.
Atlantis AIO, a tool available to hackers on the dark web, gives threat actors an automated tool to rapidly test millions of stolen credentials against email, ecommerce, and other online accounts on more than 140 email and other platforms in credential-stuffing attacks.
The post Hackers Use Atlantis AIO Tool to Automate Account Takeover Attacks appeared first on Security Boulevard.
Before we get started, if you’d prefer to listen to a 10-minute presentation instead of or to supplement reading this post, please check out the recording of our most recent BloodHound Release Recap webinar. You can also sign up for future webinars here.
Back in August, a BloodHound Enterprise (BHE) customer told us that they had implemented an Active Directory (AD) setting called BlockOwnerImplicitRights to help address some attack paths related to object ownership (e.g., Owns, WriteOwner), but the findings were still present in their graph.
Until this point, I had assumed that the owner of an AD object was always implicitly granted permissions to modify that object’s security descriptor to compromise the underlying computer/user (WriteDacl). This is the logic the Owns and WriteOwner edges were built upon. What was this setting I’d never heard of?
The first thing our team did was review the Microsoft documentation to estimate the work effort in removing these false positives.
Turns out, Microsoft introduced BlockOwnerImplicitRights as the 29th bit in a forest’s dSHeuristics attribute to prevent a vaguely-worded vulnerability where a user with permission to create computer-derived AD objects could modify security descriptors and sensitive attributes to elevate privileges in certain scenarios.
According to Microsoft, “The Owner of a security descriptor is implicitly granted READ_CONTROL and WRITE_DAC rights by default… these implicit rights are blocked when the following are TRUE:
Next, we read Jim Sykora’s excellent Owner or Pwned whitepaper, which dives into a lot more technical detail on which principal becomes the owner when objects are created, what owner permissions are abusable in different scenarios, and proactive and reactive considerations for implementing preventative controls. I highly recommend reading it to dive further into these concepts.
Now things were starting to make sense. If I understood correctly, enforcing the BlockOwnerImplicitRights bit of the dSHeuristics attribute could prevent certain scenarios we have exploited in real customer environments during offensive operations.
Consider this example:
An organization’s server team uses a specific account to programmatically join new systems to the domain, for example using Microsoft Configuration Manager (formerly SCCM — I physically can’t write a post without mentioning it) or a PowerShell script.
Remember, the account that joins a computer to the domain becomes the owner of the created object in many scenarios (detailed further in Jim’s whitepaper).
Years later, a computer joined to the domain by this account is promoted to a domain controller or is added to tier zero and is now susceptible to WriteDacl abuse via the owner’s implicit rights if the account that joined the system to the domain is compromised.
We have encountered many scenarios where ancient domain join credentials are exposed in a script on a file share or user’s desktop or can be decrypted from the SCCM operating system deployment task sequence, allowing us to compromise every computer they joined to the domain via their implicit WriteDacl permission.
Enter the BlockOwnerImplicitRights attribute.
If implicit ownership rights are blocked for these computer objects, the account that joined a computer to the domain cannot easily compromise the underlying machine via implicit WriteDacl abuse, unless they are already a member of Domain Admins/Enterprise Admins.
Implicit owner rights are also blocked when an ACE explicitly grants a permission to the OWNER RIGHTS SID (S-1–3–4). In this case, the owner is only granted the specific permissions in these ACEs. Here is another reference explaining use cases for this SID.
To fully understand the mechanics of these settings and how they impacted BloodHound, Matt Creel (@Tw1sm) got to work redesigning the Owns edge to eliminate false positives and accurately depict where these security features were enabled.
First, we needed to create a new edge called OwnsLimitedRights to identify any specific permissions granted to the object owner when an ACE is defined for the OWNER RIGHTS SID.
To summarize, implicit ownership rights are blocked if either of the following conditions are true:
OR
We landed on this design for the Owns and OwnsLimitedRights edges that were updated/introduced in BloodHound v7.1.0.
How are WriteOwner permissions impacted by these changes?
Matt found that this was a bit more complex because ACEs defining permissions for the OWNER RIGHTS SID that are not inherited (i.e., are explicitly defined) are removed from objects when their owner changes.
As a result, we needed to check whether any ACE granted rights to the OWNER RIGHTS SID (S-1–3–4), whether such an ACE was inherited or explicitly defined, and whether it granted abusable permissions in order to correctly depict the WriteOwner edge. We also created a new edge called WriteOwnerLimitedRights that identifies specific abusable permissions granted to the OWNER RIGHTS SID.
We landed on this design for the WriteOwner and WriteOwnerLimitedRights edges, which are also in BloodHound since v7.1.0:
I picked up where Matt left off to implement these changes with a ton of help from Rohan Varzarkar (@CptJesus) and John Hopper, our Director of Engineering.
To process the outcome of each of these scenarios, we needed to compare the forest’s dSHeuristics attribute value to the ACEs on each domain object. Since we don’t know what order data will be uploaded to BloodHound in or whether it’s complete (e.g., only the computers.json or domains.json file is uploaded), that meant we had to add portions of the logic to post-processing, which is the phase that occurs after ingestion of all data during a single upload.
Other portions of the logic could be created during the ingestion phase itself, such as creating edges when the OWNER RIGHTS SID is explicitly granted abusable permissions, in which case we never need to look at the dSHeuristics attribute since implicit owner rights are never granted.
To make the change backwards-compatible with previous SharpHound and third-party collector versions and as lightweight as possible, we wanted to avoid collecting every single ACE (as opposed to only abusable ACEs like SharpHound had always done), but we also needed to know whether any non-abusable permissions were granted to the OWNER RIGHTS SID and whether any such permissions were inherited. As a result, we created two new boolean properties for each object, DoesAnyAceGrantOwnerRights and DoesAnyInheritedAceGrantOwnerRights.
While coding and wiring everything together, we had to account for several other complex scenarios. For example, when both explicitly defined, abusable permissions and inherited, non-abusable permissions are granted to the OWNER RIGHTS SID, the explicitly defined permissions are deleted on ownership change but the inherited ones are not, so the Owns ACE is abusable but WriteOwner ACEs are not. In other cases where explicitly defined, non-abusable permissions are granted to the OWNER RIGHTS SID, the Owns ACE is not abusable. However, those explicitly defined permissions are deleted on owner change, so WriteOwner ACEs could be abusable if the forest’s BlockOwnerImplicitRights attribute is not set or if it is set but the object is not a computer-derived type.
The good news is, BloodHound does all of this processing for you now!
These changes resulted in the following PRs:
As well as an update to BHE.
The majority of the ingest and post-processing logic is implemented in these files:
We learned that implementing these changes eliminated a ton of false positives from the graph for BloodHound users who block owner implicit rights. Users also get the OwnsLimitedRights and WriteOwnerLimitedRights edges “for free”, regardless of what collector they use, because these edges do not depend on collection of dSHeuristics or non-abusable OWNER RIGHTS ACEs.
In the diagrams below:
Thanks for reading! If you have any questions or feedback for this post, please reach out to me (@_Mayyhem) on Twitter or in the BloodHound Slack (@Mayyhem)!
Do You Own Your Permissions, or Do Your Permissions Own You? was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
The post Do You Own Your Permissions, or Do Your Permissions Own You? appeared first on Security Boulevard.
Journalists aren’t usually invited to online chats about US war plans. This seemed obvious until yesterday, when Atlantic editor Jeffrey Goldberg published his article about being a lurker in an online chat with US Secretaries of State, Defense, and Treasury, plus the VP and the Director of National Intelligence. The plans led to a US […]
The post War Plan Chat Includes Journalist appeared first on Security Boulevard.
Author/Presenter: Christian Dameff
Our sincere appreciation to BSidesLV, and the Presenters/Authors for publishing their erudite Security BSidesLV24 content. Originating from the conference’s events located at the Tuscany Suites & Casino; and via the organizations YouTube channel.
The post BSidesLV24 – IATC – Health Care Is In Intensive Care appeared first on Security Boulevard.
Actions from a real-life breach raises questions about poor password hygiene accountability and why users, policies, and security controls must work together.
The post The Password Hygiene Failure That Cost a Job | Grip Security appeared first on Security Boulevard.
Go beyond GitHub's scope. Understand the full picture of your secret leaks with GitGuardian, covering public and internal exposures.
The post GitGuardian’s Secrets Risk Assessment: Know Your True Exposure For Free appeared first on Security Boulevard.
How authentication works, the difference between 2FA and MFA, and the various types of secondary authentication factors.
The post Two-Factor Authentication (2FA) vs. Multi-Factor Authentication (MFA) appeared first on Security Boulevard.
via the comic humor & dry wit of Randall Munroe, creator of XKCD
The post Randall Munroe’s XKCD ‘Lungfish’ appeared first on Security Boulevard.
For years, AppSec and product security teams have been locked in endless debates about the most effective security frameworks and risk scoring methodologies. From CVSS and MITRE ATT&CK to NIST frameworks, these tools promise to quantify and manage security risks—but how truly helpful are they?
The Vulnerability Industrial Complex
The unfortunate reality is that many security frameworks serve vendors more than they serve overworked security teams. These frameworks often become complex tools for justifying new tooling purchases rather than genuinely reducing security risk. It isn't uncommon for enterprises to wrestle with tens of millions of vulnerabilities, creating an overwhelming landscape of potential threats.
Traditional risk scoring has become a simplified veneer attempting to mask the intricate complexities of security risk management. Organizations desperately need a more intelligent, adaptive approach.
Introducing Agentic Risk ScoringToday, Impart is revolutionizing risk scoring by leveraging large language models (LLMs) to generate custom risk scoring policies tailored to each organization's unique security needs.
How Agentic Risk Scoring WorksOur innovative solution empowers security teams to:
The platform intelligently identifies key risk factors, creates custom detection rules, and adapts scoring weights based on the organization's specific requirements.
A Transparent, Flexible ApproachUnlike traditional black-box solutions, Impart's platform provides:
Powered by AgentOS, the system can:
Our VisionWe're not just offering another tool—we're providing a paradigm shift in security risk management. By combining advanced AI with deep security expertise, we're giving teams the ability to define their security posture on their own terms.
No more hardcoded risk rules. Just intelligent, adaptive security that works the way you do.
Join Our BetaWe're inviting forward-thinking security teams to experience this smarter, more adaptive approach to risk assessment. If you're ready to transform how you manage security risks, we want you in our beta program.
The post Introducing Agentic Risk Scoring | Impart Security appeared first on Security Boulevard.
Call it unstoppable momentum or call it yet another powerful validation of our breach-readiness approach. We’re riding high into RSA 2025 with triple Gold medals, and one Silver medal from the Globee Cybersecurity Awards. Claiming top honors for Microsegmentation, Healthcare Cybersecurity Solutions, and Pharmaceuticals & Biotech Cybersecurity Solutions, plus a Silver for Operational Technologies (OT) […]
The post ColorTokens’ Gold Rush at Globee Awards appeared first on ColorTokens.
The post ColorTokens’ Gold Rush at Globee Awards appeared first on Security Boulevard.
Alisa Viejo, United States, 25th March 2025, CyberNewsWire
The post Active Roles Wins 2025 Cybersecurity Excellence Award for Hybrid Active Directory Protection appeared first on Security Boulevard.
Author/Presenter: Dean Ford
Our sincere appreciation to BSidesLV, and the Presenters/Authors for publishing their erudite Security BSidesLV24 content. Originating from the conference’s events located at the Tuscany Suites & Casino; and via the organizations YouTube channel.
The post BSidesLV24 – IATC – Blood in the Water: Preparing For the Feeding Frenzy appeared first on Security Boulevard.
