Archive

Archive

1489 bookmarks
Custom sorting
You Already Have Our Personal Data, Take Our Phone Calls Too (FreePBX CVE-2025-57819)
You Already Have Our Personal Data, Take Our Phone Calls Too (FreePBX CVE-2025-57819)
We’re back - it’s a day, in a month, in a year - and once again, something has happened. In this week’s episode of “the Internet is made of string and there is literally no evidence to suggest otherwise”, we present even further evidence that as a species we made a fairly painful mistake when we discovered electricity - and it just got worse and worse. Today, inside this hellscape we call the Internet, a mean person has discovered a zero-day(s) in FreePBX (now lovingly called CVE-2025-57819).
#freepbx#rce#sqli
·labs.watchtowr.com·
You Already Have Our Personal Data, Take Our Phone Calls Too (FreePBX CVE-2025-57819)
Out-of-bound read in ANGLE CopyNativeVertexData from Compromised Renderer
Out-of-bound read in ANGLE CopyNativeVertexData from Compromised Renderer
Introduction Back in the beginning of the year 2024, we started our project on ANGLE, it is a chromium graphic library, handling rendering stuff on chrome process. Fortunately, our team found some of the vulnerabilities in different areas (suto has shared some information on his tweet previously). In this blog post, we will explain how a libANGLE integer underflow bug can be turned into a powerful primitive that allows us to read the Chrome WebGPU process.
#chrome#chromium#exp writers
·qriousec.github.io·
Out-of-bound read in ANGLE CopyNativeVertexData from Compromised Renderer
Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory
Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory
Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory   When Microsoft Incident Response (formerly DART/CRSP) is engaged during an incident, almost all environments include an on-premises Active Directory component. In most of these engagements, threat actors have taken full control of Active Directory –i.e., total domain compromise.   Total domain compromise often starts with the compromise of a regular non-privileged user rather than a domain admin. Threat actors can use that account to discover misconfiguration and attack paths in Active Directory that lead to full domain control. Oftentimes, threat actors leverage freely available tools such as AdFind, AD Explorer, or BloodHound to find attack paths through Active Directory environments. After total domain compromise, restoring trust back into Active Directory can take significant time and investment.   To aid in our investigations, Microsoft Incident Response leverages a custom-built Active Directory enumeration tool to retrieve metadata about users, groups, permissions, group policies and more. Microsoft Incident Response uses this data to not only aid in the investigation, but also to shape attacker eviction and compromise recovery plans and to provide best practice recommendations on taking back and maintaining positive identity control. In addition to the Microsoft Incident Response custom tool, there are other tools, such as Defender for Identity, and open-source tools such as BloodHound and PingCastle, that you can use to secure Active Directory in your own environment.   Across all industry verticals, Microsoft Incident Response often finds similar issues within Active Directory environments. In this blog, we will be highlighting some of the most common issues seen in on-premises Active Directory environments and provide guidance on how to secure those weaknesses. These include:   Initial Access – Weak password policies, excessive privilege and poor credential hygiene, insecure account configuration Credential Access – Privileged credential exposure, Kerberoasting, insecure delegation configuration, Local Administrator Password Solution (LAPS) misconfiguration, excessive privilege via built-in groups Privilege Escalation – Access control list (ACL) abuse, escalation via Exchange permissions, Group Policy abuse, insecure trust configuration, compromise of other Tier 0 assets   Initial Access Weak Password Policies It is not uncommon for Microsoft Incident Response to engage with customers where accounts have weak or easy to guess credentials, including those of privileged users such as Domain Admins. Simple password spray attacks can lead to the compromise of such accounts. If these standard user accounts are provided VPN or remote access without multi-factor authentication, the risk is increased: threat actors can connect to the VPN via devices in their control and begin reconnaissance of the environment remotely. From here, a threat actor can then attempt to escalate to Domain Admin privileges via weaknesses in Active Directory.   Recommendation Where possible, Microsoft Incident Response recommends deploying passwordless authentication technology, such as Windows Hello for Business (which uses biometrics such as facial recognition or fingerprints) or FIDO2 security keys. Fully deploying passwordless authentication allows you to disallow password authentication, which eliminates password-based attack vectors (such as password sprays and phishing) for those users. If you are not yet ready to begin deploying passwordless solutions, you can increase the strength of your on-premises password policy through group policy and fine-grained password policies. Current guidance recommends longer (14 or more characters) but less complex passwords (no special characters or similar required), with users having to change them much less frequently. This discourages users from cycling through easy-to-guess passwords to satisfy complexity and rotation requirements, such as changing their password from ‘Monday10’ to ‘Monday11’.   If you are licensed for Azure Active Directory P1 or higher, you can also deploy Azure Active Directory Password Protection, which can disallow your users from using easy to guess passwords even in on-premises Active Directory. You can also ban custom words unique to your business, such as the name of your company or the city in which you operate.   For both passwordless and stronger password policies, if you work in a complex environment where the rollout of those solutions may take some time, start by targeting your Domain Admins and other privileged users. Your Tier 0 accounts can, and should, be held to a higher security standard.   Excessive Privilege and Poor Credential Hygiene One of the most common issues found in Active Directory is accounts, particularly service accounts, being assigned too much privilege. In Microsoft Incident Response engagements, it is not uncommon to find multiple service accounts and named user accounts to be granted Domain Admin privileges. Additionally, service accounts used for applications or scripts are often granted local administrative access over all workstations and servers. Though this is an easy way to allow a product or script to function, these accounts then become a weak point in your security.   Service accounts are attractive targets because the passwords are rarely rotated. Security controls for them are often weaker, and they can’t be protected by MFA. Furthermore, the passwords for these accounts are often stored in clear text, whether that be sent in email, saved to text files on devices, or used in clear text in command line arguments. The combination of many Domain Admin accounts and poor technical controls over those accounts increase the risk for credential theft.   This excessive privilege also extends to too many users having local administrative rights on their own devices. If a compromised user does not have local administrative rights on their device, it is harder for a threat actor to continue to move laterally in the environment from that device.   Recommendation There is no specific guidance on how many Domain Admin accounts should exist in each environment, as the requirements for privileged accounts will be unique for each environment. With that said, any requests to have additional Domain Admins should be scrutinized closely, with the preference always being to grant a lower level of privilege, particularly to service accounts. Even though adding service accounts to Domain Admins is an easy way to ensure an application works, most of these accounts can be assigned much less privilege and still function correctly. They can also often be granted access to only a subset of devices rather than all workstations and servers.   If you don’t have strong controls to govern secure credential practice for your most important accounts, then the more Domain Admin level accounts you add, the more risk you incur. For service accounts, investigate whether Group Managed Service Accounts (gMSA), which can provide automatic password management, would be suitable for the workload.   Insecure Account Configuration In Active Directory, misconfiguration can be a reason the security of individual user accounts is weaker than it could be. Some of the settings to scrutinize for proper configuration include:   Do not require Kerberos pre-authentication. Store password using reversible encryption. Password not required. Password stored with weak encryption. Enabling any of these settings drastically reduces the security of an account. An adversary can enumerate a directory with relative ease to find any accounts that have these flags. The credentials for these accounts may then be easier for a threat actor to retrieve.   Recommendation Defender for Identity, via the Secure Score portal, provides an excellent summary of these risky account flags. For each configuration item, it lists which accounts are affected and how to remediate the issue. Other tooling such as BloodHound or PingCastle can also flag these account issues.   Credential Access Privileged Credential Exposure During cyber-attacks, adversaries often seek to obtain privileged credentials. These credentials are viewed as ‘crown jewels’ because they allow threat actors to complete their objectives. Once privileged credentials are obtained, they can be used to:   Add additional persistence mechanisms, such as scheduled tasks, installing services, or creating additional user accounts. Disable or bypass endpoint antivirus or other security controls. Deploy malware or ransomware. Exfiltrate sensitive data. As administrators log on to devices directly or connect to devices remotely to complete their day-to-day work, they may leave behind privileged credentials. Threat actors can leverage tools such as Mimikatz or secretsdump (part of the Impacket framework) to retrieve those credentials. As privileged users log on to more and more machines, attackers have additional opportunities to locate and extract those credentials. For example, if members of the Domain Admins group regularly log on to end user workstations to troubleshoot issues, then Domain Admin credentials may be exposed on each device, increasing a threat actor’s chances of locating and extracting them.   To help customers understand this privileged credential spread, Microsoft Incident Response collects logon telemetry from the event logs on devices, signals from Microsoft Defender for Endpoint, or both. From that data, a map is created of Tier 0 accounts, such as Domain Admins, logging onto devices that are not considered Tier 0, such as member servers and workstations.   Figure 1: Map of Domain Admin login paths to non-Tier 0 servers.   In this visual, the green circles represent Domain Admins. The red dotted lines represent RDP lo...
#active-directory
·techcommunity.microsoft.com·
Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory
Anti-detect tools | DataDome
Anti-detect tools | DataDome
Are users accessing your site while masking their true identity, device, or behavior? You’re not alone. A growing number of actors now rely on anti-detect browsers to spoof fingerprints, rotate identities, and bypass detection systems. To help you stay ahead, we’ve compiled essential information on the most commonly used anti-detect tools—and how to detect and defend against them effectively.
#cloaking
·datadome.co·
Anti-detect tools | DataDome