Category Archives: email

UK ICO Fines Vote Leave £40,000 for Unsolicited Texts

The UK’s Information Commissioner’s Office (“ICO”) has fined Vote Leave Limited (the UK’s official Brexit campaign) £40,000 for sending almost 200,000 unsolicited texts promoting the aims of the campaign. In an unrelated action, the ICO has carried out searches of a business believed to have been responsible for initiating nuisance telephone calls. The ICO has highlighted nuisance calls, spam texts and unsolicited direct marketing as areas of “significant public concern,” and is increasingly imposing sanctions on businesses that infringe the Privacy and Electronic Communications Regulations 2003 (“PEC Regulations”), which prohibit these practices. In its view, the monetary penalty imposed on Vote Leave should act as a “deterrent against non-compliance, on the part of all persons running businesses currently engaging in these practices.”

During January 2019, the ICO reportedly investigated 83 cases relating to unsolicited calls and texts. During the same month, more than 4,000 complaints were made by consumers about unsolicited live calls, and more than 5,000 of January’s complaints related to unsolicited automated calls.

The PEC Regulations, which incorporate the EU’s ePrivacy Directive into domestic law in the UK, require organizations, when making live calls, to state the identity of the caller and allow its number to be displayed to the receiver of the call. Callers must also ensure that the number they are calling has not been registered with the Telephone Preference Service (“TPS”) or Corporate TPS, indicating that individuals and businesses have opted out of receiving live marketing calls.

When conducting automated calls, the requirements are stricter: organizations must obtain specific consent prior to making such calls. With regard to texts, which fall within the definition of “electronic mail,” organizations must similarly obtain opt-in consent unless the “soft opt-in” rules apply.

On March 12, 2019, the ICO announced that following a year of investigation, it had searched two addresses of a business believed to have been making nuisance calls. The searches were carried out using the ICO’s power to enter and inspect under Regulation 31(1) of the PEC Regulations. The business in question was searched under suspicion of making both live and automated nuisance calls relating to road traffic accidents and personal injury claims, as well as insurance for household goods. Almost 600 complaints were made to the ICO in relation to these calls, in which the business failed to identify itself or offer an opt-out in relation to future calls.

Subsequently, on March 19, the ICO announced the fine it had imposed on Vote Leave, stating that the campaign was unable to provide evidence that those individuals who received its text messages had provided their consent. Political campaigns are required to comply with the law in the same way as any other business. Vote Leave stated that the individual recipients of its texts had initially made approaches to the campaign, but that evidence of any consent was deleted following the conclusion of the campaign.

The ePrivacy Directive is under review, with a draft ePrivacy Regulation currently being considered by the European Council before trilogue negotiations take place. It is not expected to be approved before the European Parliament elections in May 2019.

NC County Government Suffers Third Ransomware Infection in 6 Years

A county government in North Carolina has suffered a ransomware infection for the third time in the past six years. According to a statement published on its website, the Orange County government observed on 18 March that a virus had infected its network. It responded by shutting down all servers, which rendered public computers at […]… Read More

The post NC County Government Suffers Third Ransomware Infection in 6 Years appeared first on The State of Security.

What Security Threats of the Past Can Tell Us About the Future of Cybersecurity

Remember the Love Bug virus? Security veterans will remember that, nearly 20 years ago, the computer worm also known as ILOVEYOU spread like wildfire across email systems and networks because we believed it was a legitimate email from someone we knew. Security threats were in their infancy at that point, and most users weren’t yet tuned in to know the difference between a real email and an attack from threat actors.

The Love Bug worked for two reasons: First, it relied on email to spread, and you can’t shut down email. Second, it used social engineering tactics to generate user buy-in. Once the virus was launched on your computer, it sent the same email message to everyone in your address book. The virus also overloaded computer networks and manipulated files. It was a cybersecurity wake-up call; one of the first examples of how easy it was to use the burgeoning internet for malicious purposes.

We’ve come a long way since the Love Bug when it comes to improving overall security efforts and addressing cyberthreats. Attackers have also come a long way over the past two decades as their tactics become more sophisticated and harder to detect. However, as Josh Zelonis, senior analyst with Forrester, told the audience at Check Point’s recent CPX 360 conference, many companies are still challenged by Love Bug-like attacks.

Here we are, moving quickly toward fifth-generation cyberattacks — where we will see a rise in security threats involving the internet of things (IoT) and more cryptojacking — yet we continue to fall for basic social engineering attacks. Perhaps we can begin to develop defensive strategies for the future of cybersecurity by better understanding the threat landscape of the past.

Consistency Across Generations of Attacks

The way we share information has been a primary driver of how we approach cybersecurity. When data was exchanged via floppy disks in a controlled environment, organizations didn’t need to prioritize information security. When we began to share data online, a simple firewall was enough to keep bad guys out. The Love Bug helped give rise to signature-based virus detection, but with how fast malware moves these days, antivirus software is often no longer effective because it can’t find attacks before they cause damage to your system(s).

As attacks grow more sophisticated, we’re also seeing the same tried-and-true attack methods. Social engineering remains a preferred method for spreading malware; phishing attacks were up 250 percent between January and December 2018, according to Microsoft.

According to Frank Downs, director of cybersecurity practices at ISACA, we’re seeing consistency in the type of attacks used as well as attackers’ the end goals.

“These trends identify that while certain cybersecurity considerations change, proven attackers, victims and attack processes will never go out of style,” wrote Downs in an ISACA Now blog post.

Anticipating Future Security Threats Before They Happen

Not only do cybercriminals like to use time-tested methods of attacks, but if we pay attention, we can see signs of next-generation security threats months or even years before they happen. For example, Zelonis pointed out that the Morris worm, which was released in 1988 and is considered one of the first major cyberattacks, had third-generation components 12 years before the industry reached Gen III maturity. Similarly, the Shamoon virus had Gen V abilities five years early.

Then there was Stuxnet, which was designed to disrupt, deny and destroy. The malicious worm was discovered in 2010 in overseas nuclear systems, but was believed to have been in development for years before that. Fast forward to IoT devices and the consumer market: What we know about Stuxnet — including how it works and what its intents are — should be a primer for the types of attacks to expect on the IoT.

We already have much of the technology we need to address the next generation of attacks in place. Now, we need to focus less on adding new technologies to meet new security challenges and instead develop new strategies to stop threats. We’ve out-innovated our capabilities, and now is the time to rethink the way we approach our defenses.

If we look close enough, many new security threats are similar to things we’ve seen in other forms or attack styles we’ve previously defended against. Fully understanding the threats of the past can help us better anticipate what is to come for the future of cybersecurity — a tactic that may finally put our defenses ahead of threat actors.

The post What Security Threats of the Past Can Tell Us About the Future of Cybersecurity appeared first on Security Intelligence.

Latest tactics used by cybercriminals to bypass traditional email security

Cybercriminals are continuously using new strategies to get past email security gateways, with brand impersonation being used in 83 percent of spear-phishing attacks, while 1 in 3 business email compromise attacks are launched from Gmail accounts. Sextortion scams, a form of blackmail that makes up 10 percent of all spear-phishing attacks, continue to increase. Employees are also twice as likely to be the target of blackmail than business email compromise. These are the key findings … More

The post Latest tactics used by cybercriminals to bypass traditional email security appeared first on Help Net Security.

Brute-Force Attack Wave Uses Legacy Protocols, Credential Dumps to Compromise Cloud Accounts

A massive brute-force attack campaign used both legacy protocols and credential dumps to compromise cloud user accounts.

In a six-month study, Proofpoint observed a wave of brute-force attacks that originated mainly from Nigeria but also China, the U.S., Brazil and South Africa. These malicious operations abused various legacy protocols in the process; the vast majority leveraged IMAP, a legacy authentication protocol that bypasses multifactor authentication (MFA). Concurrently, the campaigns referred to several credential dumps to obtain username-password variations.

The attacks relied on compromised network devices such as routers and servers to conduct IMAP-based password-spraying attacks. These brute-force attempts were successful 44 percent of the time, according to Proofpoint. In those cases, the malefactors used the compromised credentials to steal access to users’ cloud application accounts. They then abused that access to send out phishing attacks to move laterally throughout the network and/or prey upon users employed at other organizations.

Not the First Brute-Force Attack Campaign to Involve IMAP

IMAP has been involved in similar operations in the past. Back in 2017, for instance, security researcher Stephen Atty discovered what appeared to be a slow-moving botnet sending out POP3/IMAP attempts at a slow rate so as to not raise any red flags with monitoring software. More than a year later, Roger Comply reported in Paranoid Penguin that he had observed another botnet using what he called the “drip” approach in its login attempts against targeted IMAP servers.

How to Strengthen Your Organization’s Email Defenses

Security professionals can help strengthen their organization’s email security posture by taking a layered approach to email defenses. This strategy should begin with the deployment of an external solution capable of scanning email for threats. They should also seek budget to create an email security awareness program to train the entire workforce to recognize, avoid and report phishing attacks.

The post Brute-Force Attack Wave Uses Legacy Protocols, Credential Dumps to Compromise Cloud Accounts appeared first on Security Intelligence.

More Than 2 Billion Unencrypted Records Exposed in Major Email Leak

A recent security incident that began as an email leak exposed more than 2 billion records containing email addresses and other personal information.

On Feb. 25, Security Discovery came across a MongoDB instance left unprotected by a password on the internet. Security researcher Bob Diachenko peered inside the exposed resource and discovered 150 GB of data, including just under 800 million email addresses. Some of the records also included personally identifiable information (PII) such as dates of birth, gender and phone numbers.

As it turned out, the scale of the incident was much larger than originally reported. Andrew Martin, CEO and founder of DynaRisk, told SC Media UK that his company’s analysis revealed how the security incident had exposed four databases, not just one. These databases contained a total of 2,069,145,043 records, with some of the files holding employment information among other pieces of data. DynaRisk also determined that all of the records were unencrypted at the time of exposure.

A Stream of MongoDB Security Events

This isn’t the only large data breach to make headlines in 2019. Near the beginning of the year, security researcher Troy Hunt revealed how the Collection #1 breach had exposed nearly 800 million email addresses and more than 21 million passwords. Shortly thereafter, PCWorld reported that the Collection #1 data breach was part of a larger set of security incidents. With the addition of Collections #2–#5, the “Collections” breaches exposed a total of 2.19 billion records.

The incident found by Security Discovery isn’t the only one to involve an unsecured MongoDB, either. In September 2018, for instance, Diachenko revealed how an unprotected MongoDB instance had exposed 11 million records. Several months later, ZDNet found that digital attackers were still holding unsecured MongoDB databases for ransom — two years after these types of security incidents first began.

How to Defend Against a MongoDB-Based Email Leak

Security professionals can help defend their organizations’ MongoDB databases from an email leak by tailoring data encryption to fit their needs, such as by combining storage-level encryption for performance and structured data encryption on certain high-risk apps. Organizations should also implement other MongoDB security best practices, which include enabling access control and auditing system activity.

The post More Than 2 Billion Unencrypted Records Exposed in Major Email Leak appeared first on Security Intelligence.

Your trust, our signature

Written and researched by Mark Bregman and Rindert Kramer

Sending signed phishing emails

Every organisation, whatever its size, will encounter phishing emails sooner or later. While the number of phishing attacks is increasing every day, the way in which phishing is used within a cyber-attack has not changed: an attacker comes up with a scenario which looks credible enough to persuade the target to perform a certain action like opening an attachment or clicking on a link in the email. To avoid such attacks the IT or security team will tell users to check for certain things to avoid falling for these phishing emails. One of the recommendations is to check if the email is digitally signed with a valid certificate. However, in this blog, we present an attack that abuses this recommendation to regain the recipient’s trust in the sender.

Traditional phishing

Countless organizations have fallen victim to traditional phishing attacks where the attacker tries to obtain credentials or to infect a computer within the target network. Phishing is a safe way to obtain such footholds for an attacker. The attacker can just send the emails, sit back and wait for the targets to start clicking.

At Fox-IT we receive lots of requests to run simulated phishing attacks; so our team sends out hundreds of thousands of carefully crafted emails every year to clients to simulate phishing campaigns. Whether it’s a blanket campaign against the entire staff or a spear phishing one against targeted individuals, the big issue with phishing stays the same; we need to persuade one person to follow our instructions. We are looking for the weakest link. Sometimes that is easy, sometimes not so much. But an attacker has all the time in the world. If there is no success today, then maybe tomorrow, or the day after…
To create security awareness among employees, IT or the security team will tell their users to take a close look at a wide variety of things upon receiving emails. Some say you have to check for spelling mistakes, others say you have to be careful when you receive an email that tries to force you to do something (“Change your password immediately, or you will lose your files”), or when something is promised (“Please fill in this survey and enter the raffle to win a new iPhone”).

SPF records

Some will tell their users to check the domain that sent the email. But others might argue that anyone can send an email from an arbitrary domain; what’s known as ‘email spoofing’.

Wikipedia defines this as:

Email spoofing is the creation of email messages with a forged sender address. Because the core email protocols do not have any mechanism for authentication, it is common for spam and phishing emails to use such spoofing to mislead the recipient about the origin of the message.

— Wikipedia https://en.wikipedia.org/wiki/Email_spoofing

This means that an email originating from the domain “ fox-it.com ”, may not have been sent by an employee of Fox-IT. This can be mitigated by implementing Sender Policy Framework (SPF) records. In an SPF record you specify which email servers are allowed to send emails on behalf of your domain. If an email originating from the domain “ fox-it.com ” was not sent by the email server specified in the SPF record, the email message can be flagged as SPAM. By using SPF records you know that the email was sent by an authorized email server, SPF records however, do not disclose the authenticity of the sender. If a company has configured their SMTP server as an open relay server, users can send mail on another user’s behalf which will pass the SPF record check on the receivers end. There are other measures that can be used to identify legitimate mail servers to reduce phishing attacks, such as DKIM and DMARC, however, these are beyond the scope of this blogpost.

What is a digital signature?

To tackle the problem of email spoofing some organizations sign their emails with a digital signature. This can be added to an email to give the recipient the ability to validate the sender as well as the integrity of the email message.
For now we’ll focus on the aspect of validating the sender rather than the message integrity aspect. When the email client receives a signed email, it will check the attached certificate to see who the subject of the certificate is (i.e.: “john.doe@fox-it.com “). The client will check if this matches the originating email-address. To verify the authenticity of the digital signature, the email client will also check if the certificate is issued (signed) by a reputable Certificate Authority (CA). If the certificate is signed by a trusted Certificate Authority, the receiving email client will tell the recipient that the email is signed using a valid certificate. Most email clients will in this case show a green checkmark or a red rosette, like the one in the image below.

6oQvhoK

By default there is a set of trusted Certificate Authorities in the Windows certificate store. With digital certificates, everything is based on trusting those third parties, the Certificate Authorities. So we trust that the Certificate Authorities in our Windows certificate store give out certificates only after verifying that the certificate subject (i.e.: “john@fox-it.com “) is who they say they are. If we receive a signed email with a certificate which is verified by one of the Certificate Authorities we trust, our systems will tell us that the origin of the email is trusted and validated.
Obviously the opposite is also true. If you receive a signed email and the attached certificate is not signed by a Certificate Authority which is in the Windows certificate store, then the signature will be considered invalid. It is possible to attach a self-signed certificate to an email; in which case the email will be signed, but the receiving email client won’t be able to validate the authenticity of the received certificate and therefore will show a warning message to the recipient.

OxmuNkt

Common misconception regarding email signing

Some IT teams are pushing email signing as the Holy Grail to avoid being caught by a phishing email, because it verifies the sender. And if the sender is verified, we have nothing to worry about.

Unfortunately, the green checkmark or the red rosette which accompanies a validated email signature seems to stimulate the same behavior as we’ve seen with the green padlock accompanying HTTPS websites. Users see the green padlock in their browser and think that the website is absolutely safe. Similarly, they see the green checkmark or the red rosette and make the assumption that everything is safe: it’s a signed email with a valid certificate, the sender is verified, which means everything must be OK and that the email can’t be a phishing attack.

This may be true, if alice@fox-it.com sends you a signed email with a valid certificate: the sender really is Alice from Fox-IT, provided that the private key of the certificate is not compromised. But, if alice@fox-it.cm (notice the ‘.cm’ instead of ‘.com’) sends you a signed email with a valid certificate, that person can still be anyone. As long as that person has control over the domain ‘fox-it.cm’, they will be able to send signed emails from that domain. Because many users are told that the green checkmark or the red rosette protects against phishing, they may be caught off guard if they receive an email containing a valid certificate.

Sending signed phishing emails

At Fox-IT we’re always trying to innovate, meaning in this case that we’re looking for ways to make the phishing emails in our simulations more appealing to our client’s employees. Adding a valid certificate makes them look genuine and creates a sense of trust. So when running phishing simulations we use virtual private servers to do the job. For each simulation we setup a fresh server with the required configuration in order to deliver the best possible phishing email. To send out the emails, we’ve developed a Python script into which we can feed a template, some variables and a target list. Recently we’ve updated the script to include the ability to sign our phishing emails. This results in very convincing phishing emails. For example, in Microsoft Office Outlook one of our phishing emails would look like this:

8A9oUnj

This is not limited to Office Outlook only, it is working in other mail clients as well, such as Lotus Notes. Although Lotus Notes doesn’t have a red rosette to show the user that an email is digitally signed, there are some indicators which are present when reading a signed email. As you can see below, the digital signature does still add to the legitimate look of the phishing emails:

5floNBj

Going the extra mile

The user has now received a phishing mail that was signed with a legitimate certificate. To make it look even more genuine, we can mention the certificate in the phishing mail. Since the Dutch government has a webpage1 with information about the use of electronic signatures in email, we can write a paragraph that looks something like the the one in the image below.

gov

Sign the email

The following (Python) code snippet shows the main signing functionality:

# Import the necessary classes from M2Crypto library
from M2Crypto import bio, rand, smime

# Make a MemoryBuffer of the message.
buf = makebuf(msg_str)

# Seed the PRNG.
Rand.load_file('randpool.dat', -1)

# Instantiate an SMIME object; set it up; sign the buffer.
s = SMIME.SMIME()
s.load_key('key.pem', 'cert.pem')
p7 = s.sign(buf, SMIME.PKCS7_DETACHED)

# Recreate buf.
buf = makebuf(msg_str)

# Output p7 in mail-friendly format.
out = BIO.MemoryBuffer()
out.write('From: %s\n' % sender)
out.write('To: %s\n' % target)
out.write('Subject: %s\n' % subject)

s.write(out, p7, buf)
msg = out.read()

# Save the PRNG's state.
Rand.save_file('randpool.dat')

This code originates from the Python M2Crypto documentation2

For the above code to work, the following files must be in the same directory as the Python script:
* The public certificate saved as cert.pem
* The private key saved as key.pem

There are many Certificate Authorities that allow you to obtain a certificate online. Some even allow you to request a certificate for your email address for free. A quick google query for “free email certificate” should give you enough results to start requesting your own certificate. If you have access to an inbox you’re good to go.
To get an idea of how the above code snippet can be included in a standalone script, we’d like to refer to Fox-IT’s Github page where we’ve uploaded an example script which takes the most basic email parameters (‘from’, ‘to’, ‘subject’ and ‘body’). Don’t forget to place the required certificate and corresponding key file in the same directory with the Python script if you start playing around with the example script. Link to project on GitHub: https://github.com/fox-it/signed-phishing-email

Mitigation

There are some mitigations that can make this type of attack harder to perform for an attacker. We’d like to give you some tips to help protect your organisation.

Prevent domain squatting

The first mitigation is to register domains that look like your own domain. An attacker that sends a phishing mail from a domain name that is similar to your own domain name can trick users into executing malware or giving away their credentials more easily. This type of attack is called domain squatting, which can result in examples like fox-it.cm instead of fox-it.com . There are generators that can help you with that, such as: https://github.com/elceef/dnstwist

Restrict Enhanced Key Usages

Another mitigation has a more technical approach. For that we need to look into how certificates are used. Let’s say we have an internal Public Key Infrastructure (PKI) with the following components:
* Root CA
* Subordinate CA

The root CA is an important server in an organisation for maintaining integrity and secrecy. All non-public certificates will stem from this server. Most organizations choose to completely isolate their root CA for that reason and use another server, the subordinate CA, to sign certificate requests; The subordinate CA will sign certificates on behalf of the root CA.
In Windows, the certificate of the root CA is stored in the Trusted Root Certification Authorities store, while the certificate of the subordinate CA is stored in the Intermediate Certification Authorities store.

Certificates can be used in many scenarios, for example:
* If you want to encrypt files, you can use Encrypted File System (EFS) in Windows. EFS uses a certificate to protect your data from prying eyes.
* If you have a web server, you can use a certificate to establish a secure connection with a client so that all data is transferred securely.
* Stating the obvious: if you want to send email in a secure way, you can also use a certificate to achieve that

Not every certificate can sign code, encrypt files or send email securely. Certificates have a property, the Enhanced Key Usage (EKU), that states the intended purpose of a certificate. The intended purpose can be one of the actions mentioned above, or a wildcard. A certificate with only an EKU for code signing cannot be used to send email in a secure manner.

By disabling the “Secure Email” EKU from all certification authorities, except from our own root and subordinate CA, phishing mail that is signed with a valid certificate signed by a third party CA, will still trigger a warning stating that the certificate is invalid.
To do that, we must first discover all certificates that support the secure email EKU. This can be done with the following PowerShell one-liner:

# Select all certificates where the EnhancedKeyUsage is empty (Intended Purpose -eq All)
# or where EnhancedKeyUsage contains Secure Email
Get-ChildItem -Path 'Cert:\' -Recurse | Where-Object {$_.GetType().Name -eq 'X509Certificate2' -and ({$_.EnhancedKeyUsageList.Count -eq 0} -or $_.EnhancedKeyUsageList.FriendlyName -contains 'Secure Email')} | Select-Object PSParentPath, Subject

We now know which certificates support the secure email EKU. In order to disable to secure email EKU we have to do some manual labour. It is recommended to apply the following in a base image, group policy or certificate template.

  1. Run mmc with administrative privileges
  2. Go to File, Add or Remove Snap-ins, select Certificates
    B8TQT4f
  3. Select My user account, followed by OK. Please note that this mitigation requires that certificates in all certificates stores must be edited.
    CpRQtRz

    1. Check if intended purpose states Secure email or All
      175MRhH
  4. Open the properties of a certificate and click the details tab

If the intended purpose at step 3.1 stated All,
1. Click Key Usage, followed by Edit Properties.
iFPwV2x
2. Click Enable only the following purposes and uncheck the Secure Email checkbox
8nhvj29

If the intended purpose at step 3a stated Secure Email,
1. Click Enhanded key usage (property)
EHH4vBz
2. Click Edit Properties…
3. Uncheck the Secure Email checkbox
8nhvj29

Please keep the following in mind when implementing these mitigations:
* When a legitimate mail has been signed with with a certificate issues by a CA that of which the Secure Email EKU has been removed, the certificate of the email will not be trusted by Windows
* Changing the EKU may have an impact on the working of your systems
* These settings can be reverted with every update in Windows
* New or renewed certificates can have the Secure email EKU as well

This means that in order to only allow your own PKI server to have the Secure Email EKU enabled you must periodically check for certificates that have this EKU configured.

Human factor

With techniques like the one described in this blog post it becomes more and more obvious that users will never be able to withstand social engineering attacks. In a best case scenario, users will detect and report an attack, in a worst case scenario your users will become victim. It is important to perform awareness exercises and educate users, but we should accept that a percentage of the user base could always become a victim. This means that we (organizations) need to start thinking about new and more user friendly strategies in combating these type of attacks.

To summerize this blogpost:
* An email coming from a domain does not prove the integrity of the sender
* An email that is signed with a trusted and legitimate certificate does not mean that the email can be trusted
* If the domain of the sender address is correct and the email has been signed with a valid certificate signed by a trusted CA, only then the email can be trusted.

References

1: https://www.rijksoverheid.nl/onderwerpen/digitale-overheid/vraag-en-antwoord/wat-is-een-elektronische-handtekening (Dutch)
2: https://m2crypto.readthedocs.io/en/latest/howto.smime.html#m2crypto-smime “M2Crypto S/MIME”