InfoSec and Compliance – With 20 years of blogging experience, DISC InfoSec blog is dedicated to providing trusted insights and practical solutions for professionals and organizations navigating the evolving cybersecurity landscape. From cutting-edge threats to compliance strategies, this blog is your reliable resource for staying informed and secure. Dive into the content, connect with the community, and elevate your InfoSec expertise!
Security expert from Morphus Labs recently observed several malicious campaigns abusing Microsoft Build Engine (MSBuild) to execute a Cobalt Strike payload on compromised machines.
MSBuild is a free and open-source build toolset for managed code as well as native C++ code and was part of .NET Framework. It is used for building apps and gives users an XML schema that controls how the build platform processes and builds software to deliver malware using callbacks.
Morphus Labs security researcher and SANS Internet Storm Center (ISC) handler Renato Marinho revealed to have uncovered two different malicious campaigns that were abusing MSBuild for code execution.
The malicious MSBuild project employed in the attacks was designed to compile and execute specific C# code that in turn decodes and executes Cobalt Strike payload.
“Now, let’s look at the malicious MSBuild project file in Figure 3. Using the same principle, when called by MSBuild, it will compile and execute the custom C#, decode and execute the Cobalt Strike beacon on the victim’s machine.” wrote Marinho.
In the attack scenario described by the researcher, the attackers initially gained access to the target environment using a valid remote desktop protocol (RDP) account, then leveraged remote Windows Services (SCM) for lateral movement, and MSBuild to execute the Cobalt Strike Beacon payload.
The Beacon was used to decrypt the communication with the C2 server, which was SSL encrypted.
It’s an information security framework designed to reduce payment card fraud by requiring organisations to implement technical and organisational defence measures.
We explain everything you need to know about the PCI DSS in this blog, including who it applies to, the benefits of compliance and what happens if you fail to meet its requirements.
Who needs PCI DSS compliance?
Any merchant or service provider that processes, transmits or stores cardholder state is subject to the PCI DSS.
Merchants are organisations that accept debit or credit card payments for goods or services.
Service providers are businesses that are directly involved in processing, storing or transmitting cardholder data on behalf of another entity.
Some organisations can be both a merchant and a service provider. For instance, an organisation that provides data processing services for other merchants will also be a merchant itself if it accepts card payments from them.
Benefits of PCI DSS compliance
The most obvious benefit of PCI DSS compliance is to reduce the risk of security incidents. When organisations implement its requirements, they shore up the most common weaknesses that attackers exploit.
According to the 2020 Trustwave Global Security Report, the majority of data breaches involving cardholder data were CNP (card-not-present) attacks. This indicates that e-commerce platforms are the most vulnerable, but this is only half the picture.
Data protection isn’t just about preventing cyber attacks; information can also be exposed by mistakes the organization makes. Such errors can also result in violations of the GDPR (General Data Protection Regulation) and other data protection laws.
PCI DSS compliance can help organisations prevent regulatory errors and the effects associated with it.
Is PCI DSS compliance mandatory?
The PCI DSS is a standard not a law, and is enforced through contracts between merchants, acquiring banks that process payment card transactions and the payment brands.
Compliance is mandatory for all organisations that process, store or transmit cardholder data. Covered organisations that fail to meet their requirements could face strict penalties.
Notably, the Standard doesn’t simply levy a one-off fine for non-compliance. Instead, organisations can be penalised between $5,000 (about €4,300) and $100,000 (about €86,000) a month until they achieve compliance.
Organisations can also face other punitive measures from their acquiring bank. For example, the bank might increase its transaction fees or terminate the relationship with the merchant altogether.
How do I achieve PCI DSS compliance?
The PCI DSS contains 12 requirements that organisations must meet if they are to achieve compliance.
They are combination of technical solutions, such as data encryption and network monitoring, alongside processes and policies to ensure that employees manage sensitive data effectively.
Those processes include steps such as changing default passwords, restricting physical access to locations where cardholder data is stored and creating an information security policy.
How do you know if you are PCI compliant?
To demonstrate that your organisation is PCI DSS compliant, organisations must audit their CDE (cardholder data environment).
There are three types of audit:
An RoC (Report on Compliance), which must be completed by a PCI QSA (qualified security assessor) organization such as IT Governance, or by an ISA (internal security assessor).
An SAQ (self-assessment questionnaire) signed off by a company officer. There are nine types of SAQ and it is essential that you choose the correct one.
The type of audit you must conduct, and your exact PCI DSS compliance requirements, will vary depending on your merchant or service provider level. This information is based on the number of card transactions processed per year.
Level 1 merchants are those process more than 6 million transactions per year, or those whose data has previously been compromised. They must complete the following each year:
RoC conducted by a QSA or ISA.
Quarterly scan by an ASV.
Level 2 merchants are those that process 1 million to 6 million transactions per year. They must complete the following each year:
RoC conducted by a QSA or ISA, or an SAQ (SAQ D) signed by a company officer (dependent on payment brand).
Quarterly scan by an ASV
Level 3 merchants are those that process 20,000 to 1 million transactions per year. They must complete the following each year:
SAQ signed by a company officer.
Quarterly scan by an ASV (dependent on SAQ completed).
Level 4 merchants are those that process fewer than 20,000 transactions per year. They must complete the following each year:
SAQ signed by a company officer.
Quarterly scan by an ASV (dependent on SAQ completed).
The audit requirements for service providers are more straightforward. Level 1 encompasses any organisation that process and/or store more than 300,000 transactions per year. They are required to conduct a RoC by a QSA or ISA and have an ASV conduct quarterly scans.
Service providers that transmit and/or store fewer than 300,000 transactions per year must complete either an RoC conducted by a QSA or an ISA, or an SAQ D signed by a company officer. They must also have an ASV conduct quarterly scans.
Get started with the PCI DSS
As a QSA company, IT Governance provides services to support organisations at each stage of each organisation’s PCI DSS compliance project. You can find out complete list of PCI DSS services and solutions on our website.
It contains everything you need to implement the Standard’s requirements, including template documents and a document checker to ensure you select and amend the appropriate records.
The toolkit supports all self-assessment questionnaires, regardless of your specific payment scenario.
It’s fully aligned with the PCI DSS, so you can be sure that your policies are accurate and compliant. All you have to do is fill in the sections that are relevant to your organization.
Researchers from DrWeb monitored attacks leveraging exploits for vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE2021-4104, and CVE-2021-42550) in the Apache Log4j library warning of the need to adopt protective measures.
The vulnerabilities can allow threat actors to execute arbitrary code on the target systems, trigger a Denial of Service condition, or disclose confidential information.
Dr. Web set up one of its honeypots to analyze the impact of the Log4J vulnerabilities on systems exposed online and discovered an intense activity between December 17th-20th.
“We record attacks using exploits for the vulnerabilities on one of our honeypots–a special server used by Doctor Web specialists as bait for fraudsters. The most active threat occurred between December 17th-20th, but attacks still continue.” reads the analysis published by DrWeb.
Day
Number of attacks
December 10
7
December 11
20
December 12
25
December 13
15
December 14
32
December 15
21
December 16
24
December 17
47
December 18
51
December 19
33
December 20
32
December 21
14
December 22
35
December 23
36
The attacks are carried out from 72 different IP addresses, most of them were German IP addresses (21%), followed by Russia (19.4%), the USA and China (9.7%).
Security researchers spotted a campaign that is employing a new stealthy malware tracked as BLISTER that targets windows systems.
Elastic Security researchers uncovered a malware campaign that leverages a new malware and a stealthy loader tracked as BLISTER, that uses a valid code signing certificate issued by Sectigo to evade detection.
BLISTER loads second-stage payloads that are executed directly in the memory of the Windows system and maintain persistence. The malicious code has a low detection rate and implements multiple tricks to avoid detection.
“A valid code signing certificate is used to sign malware to help the attackers remain under the radar of the security community. We also discovered a novel malware loader used in the campaign, which we’ve named BLISTER. The majority of the malware samples observed have very low, or no, detections in VirusTotal.” “The infection vector and goals of the attackers remain unknown at this time.”
The certificate used to sign the loader code was issued by Sectigo for a company called Blist LLC, which has an email address from a Russian provider Mail.Ru.
The loader is embedded into legitimate libraries, such as colorui.dll, to avoid raising suspicion, it can be initially written to disk from simple dropper executables.
Upon execution, BLISTER decodes bootstrapping code stored in the resource section with a simple 4-byte XOR routine. The malware authors heavily obfuscated the bootstrapping code that initially sleeps for 10 minutes before executing in an attempt to evade sandbox analysis.
Then the loader decrypts the embedded malware payload, experts reported the use of CobaltStrike and BitRat as embedded payloads. The payload is loaded into the current process or injected into a newly pawned WerFault.exe process.
In order to achieve persistence, BLISTER copy itself to the C:\ProgramData folder and re-names a local copy of rundll32.exe. Then it creates a link to the current user’s Startup folder to launch the malware at logon as a child of explorer.exe.
Elastic’s researchers shared Yara rules for this campaign along with indicators of compromise.
Malware Analysis and Detection Engineering: A Comprehensive Approach to Detect and Analyze Modern Malware
InfoSec is the page where the InfoSec community interacts, and share InfoSec & compliance related information.
“You Become What You Think About Ask; and it shall be given to you Seek; and you shall find Knock; and it shall be opened unto you.”
As cybercrime sophistication reaches new heights, what can organizations do to tackle these new threats?
Phishing, identity theft, and ransomware are not new types of cyberattacks. What is new is bad actors increasingly using automation and other advanced technologies to more quickly identify and exploit vulnerabilities in organizations’ defenses to access or steal sensitive data without being detected.
One commonality among most attackers is their desire to achieve the most lucrative outcome. They view themselves as a business, and like any business, they want to increase their ROI. Using automated bots is an easy and inexpensive way to identify vulnerable targets and launch their attacks.
Therefore, organizations must build and enforce barriers that the criminal determines are too complex and expensive to overcome. One way to do so is by conducting extensive vetting during the new customer onboarding process that challenges customers to verify their identities. A rigorous approach to onboarding not only ensures the person creating a new user account is who they say they are and builds trust, but it will also compel a bad actor to give up and move on to their next target.
Cybercriminals have found a way to bypass the patch for a recent Microsoft Office vulnerability tracked as CVE-2021-40444 (CVSS score of 8.8). The bad news is that threat actors are using it to distribute the Formbook malware.
The CVE-2021-40444 is a remote code execution security flaw that affected the MSHTML file format.
the security defect can be exploited to achieve remote code execution on vulnerable systems. An attacker looking to exploit the bug needs to trick the indented victim into opening a maliciously crafted document.
In September Microsoft warned of multiple threat actors, including ransomware operators, that were exploiting the Windows MSHTML remote code execution security flaw in attacks against organizations.
The IT giant said that threat actors started targeting this issue on August 18, before Microsoft shared mitigation for this vulnerability, threat actors used weaponized Office documents. The campaigns observed in August 2021 employed emails impersonating contracts and legal agreements, the messages used documents that were hosted on file-sharing sites.
The availability of Proof-of-concept exploit code for this vulnerability caused a spike in attacks attempting to exploit this issue.
In the initial attacks observed by the researchers, the malicious code downloads a Microsoft Cabinet (CAB) archive containing a malicious executable. The patch developed by Microsoft prevents the execution of the code to download the CAB archive, but now threat actors are bypassing the patch by incorporating a Word document in a specially crafted RAR archive.
A critical privilege-escalation vulnerability could lead to backdoors for admin access nesting in web servers.
A popular WordPress SEO-optimization plugin, called All in One SEO, has a pair of security vulnerabilities that, when combined into an exploit chain, could leave website owners open to site takeover. The plugin is used by more than 3 million websites.
An attacker with an account with the site – such as a subscriber, shopping account holder or member – can take advantage of the holes, which are a privilege-escalation bug and an SQL-injection problem, according to researchers at Sucuri.
“WordPress websites by default allow any user on the web to create an account,” researchers said in a posting on Wednesday. “By default, new accounts are ranked as subscriber and do not have any privileges other than writing comments. However, certain vulnerabilities, such as the ones just discovered, allow these subscriber users to have vastly more privileges than they were intended to have.”
The pair is ripe for easy exploitation, according to Sucuri, so users should upgrade to the patched version, v. 4.1.5.3. Marc Montpas, a security researcher at Automattic, was credited with finding the bugs.
Microsoft released an alert on a couple of Active Directory vulnerabilities, that have been fixed with the November 2021 Patch Tuesday security updates, that could allow threat actors to takeover Windows domains.
The flaws, tracked as CVE-2021-42287 and CVE-2021-42278, can be chained to impersonate domain controllers and gain administrative privileges on Active Directory.
Microsoft is now warning customers to address both issues immediately due to the public availability of Proof-of-concept exploit code. The IT giant also published a guide to help customers in detecting the attempts of exploitation of both issues.
“Both vulnerabilities are described as a ‘Windows Active Directory domain service privilege escalation vulnerability’.A few weeks later, on December 12, 2021, a proof-of-concept tool leveraging these vulnerabilities was publicly disclosed.” states Microsoft.“When combining these two vulnerabilities, an attacker can create a straightforward path to a Domain Admin user in an Active Directory environment that hasn’t applied these new updates. This escalation attack allows attackers to easily elevate their privilege to that of a Domain Admin once they compromise a regular user in the domain.”
The CVE-2021-42278 vulnerability is a security bypass issue that allows potential attackers to impersonate a domain controller using computer account sAMAccountName spoofing.
Experts pointed out that sAMAccountName attributes usually end with “$” in their name. “$” was used to distinguish between user objects and computer objects. With default settings, a normal user has permission to modify a machine account (up to 10 machines) and as its owner, they also have the permissions to edit its sAMAccountName attribute.
Pick a random person, and ask them these two questions:
Q1.Have you heard of Apache? Q2.If so, can you name an Apache product?
We’re willing to wager that you will get one of two replies:
A1.No.A2.(Not applicable.) A1.Yes.A2.Log4j.
Two weeks ago, however, we’d suggest that very few people had heard of Log4j, and even amongst those cognoscenti, few would have been particularly interested in it.
Until a cluster of potentially catastrophic bugs – originally implemented as features, on the grounds that less is never more – were revealed under the bug-brand Log4Shell, the Log4j programming library was merely one of those many components that got sucked into and used by thousands, perhaps even hundreds of thousands, of Java applications and utilities.
Log4j was just “part of the supply chain” that came bundled into more back-end servers and cloud-based services than anyone actually realised until now.
Many sysdamins, IT staff and cybersecurity teams have spent the past two weeks eradicating this programmatic plague from their demesnes. (Yes, that’s a real word. It’s pronounced domains, but the archaic spelling avoids implying a Windows network.)
The Google Open Source Team scanned the Maven Central Java package repository and found that 35,863 packages (8% of the total) were using versions of the Apache Log4j library vulnerable to Log4Shell exploit and to the CVE-2021-45046 RCE.
“More than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities (1, 2), with widespread fallout across the software industry.” reads the report published by Google.“As far as ecosystem impact goes, 8% is enormous.”
The Google experts used the Open Source Insights, a project used to determine open source dependencies, to assess all versions of all artifacts in the Maven Central Repository.
The experts pointed out that the direct dependencies account for around 7,000 of the affected packages. Most of the affected artifacts are related to indirect dependencies.
“The deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs.” reads the post published by the researchers. “For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.”
But since the vulnerability was disclosed, 13% of all vulnerable packages have been fixed (4,620).
How long will it take for this vulnerability to be fixed across the entire ecosystem?
As Christmas 2021 approaches, spare a thought for your sysamins, for your IT team, and for your cybersecurity staff.
There may be plenty of mice stirring all through the IT house right up to Christmas Eve…
…because that’s the deadline set by the US Cybersecurity and Infrastructure Security Agency (CISA) for patching the infamous Log4Shell vulnerability, a dangerously exploitable flaw in Apache’s widely used Log4j (Logging for Java) programming toolkit.
Since news first broke of the problem on 09 December 2021, Apache has a-patched the code not once but three times, variously fixing CVE-2021-44228 with version 2.15.0, quickly followed by 2.16.0 to fix a related bug dubbed CVE-2021-45046, foillowed quickly yet again by 2.17.0 to deal with CVE-2021-45105.
Why the pressure from CISA? Why the rush when we’re supposed to enjoying a global holiday season? Why not wait until New Year and deal with things then?
Here’s why your sysadmins are taking one (three, actually) for the team…
Pegasus spyware was allegedly used by governments to spy upon prominent journalists, politicians and activists.
A Google blog has revealed how the sophisticated software was used to attack iPhone users.
The software used a vulnerability in iMessages to hack into iPhones without the user’s knowledge.
The Pegasus spyware, developed by Israel’s NSO group, made headlines for being used by governments and regimes across the world including India to spy on journalists, activists, opposition leaders, ministers, lawyers and others. The spyware is accused of hacking into the phones of at least 180 journalists around the world, of which 40 are notable Indian personalities.
Now, a Google blog from the Project Zero team called the attacks technically sophisticated exploits and assessed the software to have capabilities rivalling spywares previously thought to be accessible to only a handful of nations.
The company has also faced multiple lawsuits including one in India where the Supreme Court (SC) set up a three-member panel headed by former SC judge RV Raveendran to probe whether the software was used by the government to spy on journalists and other dissidents.
Apart from India, Apple has also sued the Israeli firm after having patched its security exploit. The company was also banned in the United States after the details of the spyware were revealed. Let’s take a look at how this advanced snooping technology discretely worked on iPhones.
According to the Project Zero blog, a sample of the ForcedEntry exploit was worked upon by the team and Apple’s Security Engineering and Architecture (SEAR) group. Pegasus attacks on iPhones were possible due to the ForcedEntry exploit.
Pegasus is a spyware (Trojan/Script) that can be installed remotely on devices running on Apple ‘ s iOS & Google ‘ s Android operating systems. It is developed and marketed by the Israeli technology firm NSO Group. NSO Group sells Pegasus to ” vetted governments ” for ” lawful interception ” , which is understood to mean combating terrorism and organized crime, as the firm claims, but suspicions exist that it is availed for other purposes. Pegasus is a modular malware that can initiate total surveillance on the targeted device, as per a report by digital security company Kaspersky. It installs the necessary modules to read the user’s messages and mail, listen to calls, send back the browser history and more, which basically means taking control of nearly all aspects of your digital life. It can even listen in to encrypted audio and text files on your device that makes all the data on your device up for grabs.
Well, in case you missed it, the renowned OpenSSL cryptographic toolkit – a free and open source software product that we’re guessing is installed somewhere between one and three orders of magnitude more widely than Log4J – also published updates this week.
OpenSSL 1.1.1m replaces 1.1.1l (those last characters are M-for-Mike and L-for-Lima), and OpenSSL 3.0.1 replaces 3.0.0.
In case you were wondering, the popular X.Y.Z versioning scheme used by OpenSSL 3 was introduced at least in part to avoid the confusion caused by the trailing letter in the earlier version “numbering” system. As for OpenSSL 2, there wasn’t one. Only the 1.1.1 and the 3.0 series are currently supported, so updating versions such as OpenSSL 1.0.x means jumping to 1.1.1m, or directly to the OpenSSL 3 series.
“Applications may not behave correctly”
The good news is that the OpenSSL 1.1.1m release notes don’t list any CVE-numbered bugs, suggesting that although this update is both desirable and important (OpenSSL releases are infrequent enough that you can assume they arrive with purpose), you probably don’t need to consider it critical just yet.
But those of you who have already moved forwards to OpenSSL 3 – and, like your tax return, it’s ultimately inevitable, and somehow a lot easier if you start sooner – should note that OpenSSL 3.0.1 patches a security risk dubbed CVE-2021-4044.
As far as we’re aware, there are no viable known exploits for this bug, but as the OpenSSL release notes point out:
[The error code that may be returned due to the bug] will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses.
In theory, a precisely written application ought not to be dangerously vulnerable to this bug, which is caused by what we referred to in the headline as error conflation, which is really just a fancy way of saying, “We gave you the wrong result.”
Simply put, some internal errors in OpenSSL – a genuine but unlikely error, for example, such as running out of memory, or a flaw elsewhere in OpenSSL that provokes an error where there wasn’t one – don’t get reported correctly.
Instead of percolating back to your application precisely, these errors get “remapped” as they are passed back up the call chain in OpenSSL, where they ultimately show up as a completely different sort of error.