ATP update – Introducing the new feature Malicious Document Decryption

ATP update – Introducing the new feature Malicious Document Decryption

In order to spread ransomware, viruses or spyware into the systems of companies and organizations, cybercriminals are constantly developing new methods: Now they are focusing on a simple but very effective way, in which their distributed malware attached to an email can bypass antivirus scanning. The infected attached document is encrypted with a password, which prevents the filtering mechanisms of antivirus programs from detecting the hidden malware.

The current threat situation requires an update of the existing filtering mechanisms: “Malicious Document Decryption”fulfills these requirements perfectly.

Just a few weeks ago, we reported about a “fake application mail” campaign that targeted HR departments in companies. This attack was performed by the ransomware GandCrab 5.2. The Hornetsecurity Security Lab still detects incoming malicious emails with encrypted and malware-infected attachments. The password for the decryption of the malicious file is visible to the recipient in the message of the email. However, decrypting the attachment downloads the hidden virus and infects the computer system.

“Malicious Document Decryption” adds another elementary feature to Advanced Threat Protection to prevent the increasing threat of hidden malware. Emails with encrypted attachments are analyzed for their potential passwords within the email in order to decrypt the attachment in the sandbox. The file is then scanned using static and dynamic analysis methods and the behavior of the file is examined during execution. This makes it possible to detect malware in encrypted files and block the corresponding emails before they reach the recipient.

The “Malicious Document Decryption” feature decrypts all encrypted Microsoft Office file types and will be extended to decrypt PDF and archive files (RAR, ZIP, etc.).
Since the beginning of June, “Malicious Document Decryption” is included in the ATP service and already activated for all existing ATP customers..

Blockchain explained easily

Blockchain explained easily

Over and over again in recent times the subject of blockchains has made the headlines. Probably the best-known representative of this technology is the Bitcoin cryptocurrency. Yet the uses to which a blockchain can be put are more diverse and are hotly discussed in the financial and insurance industries and in IT. So what exactly is a blockchain and what is the technology behind it? This blog entry looks at this question and goes on to examine the advantages that blockchains bring and the scenarios in which they can be used.

What is a blockchain?

A blockchain is essentially a decentralized digital database for the storage of data. This technology can be used to perform what are known as transactions and to verify and automate them. Transactions are data collections that are distributed to all participants (or ‘nodes’) within a particular network and subsequently collected together in blocks.
The origin of the name ‘blockchain’ is as follows. A ‘block’ is a body of stored transactions, while a ‘chain’ is formed by stringing together a number of blocks. The result is a ‘blockchain’ that is formed of multiple information blocks and is further extended by additional blocks. When this happens, the new block is always attached to the most recent block of the existing chain.

How does a blockchain work?

The individual blocks of a blockchain are created in a decentralized peer-to-peer network by means of a process called ‘mining’. In mining, transactions are verified by a consensus mechanism, validated and then joined together to form a block. The block thus formed is then chained to the existing blockchain.
The commonest consensus mechanism is the ‘proof of work’ algorithm. This is used in the Bitcoin blockchain, for example, and serves to ensure that a consensus prevails in the affected network about an identical version of the blockchain. To generate a new block, the miners must use a mathematical function – known as the hash function – to find the correct outcome of a given character string. This is done by entering various values into the hash function. The outcome of this function is predetermined, and therefore no conclusions can be drawn about the values contained within it. If the predetermined outcome and the result of the hash function employed are identical, the newly formed block is accepted and adopted by all nodes of the network.
The data of a blockchain is redundant and secure, since the data is stored on all the nodes within the network. As a result, the failure of one or more nodes does not pose the hazard of potential loss of data. Data contained within a blockchain can be neither changed nor deleted. Any manipulation would result in all subsequent blocks being invalid.

What types of blockchain are there?

Blockchains can basically be divided into three main types: public, private and consortium or federated. There are also other mixed forms that are not examined in this entry.
Public blockchain
In a public blockchain, the network is entirely decentralized. There is no central point of responsibility, so that everybody in the blockchain participates on all nodes of the network and can access the blockchain data distributed within it. Before a new transaction can be added to a block, it must be verified and synchronized by every node. This type is therefore relatively slow and resource-intensive. Public blockchains are often used with cryptocurrencies such as Bitcoin or Ethereum. All nodes within the network agree the transactions. They therefore decide which transactions are included in a new block and added to the chain.
Private blockchain
In this type there is a responsible party that operates the blockchain and undertakes the verification of the transactions. The responsible party can be a person or a company. This party also decides who may perform actions such as reading or writing. This form of blockchain has a higher level of data protection than the public variant, but it loses the fundamental notion of decentralization. The private blockchain is suitable for companies that do not wish to make their data freely accessible. Daimler and LBBW tested the use of a private blockchain in a pilot project for processing a bonded loan, from initiation through placement, allocation and conclusion of contract through to the interest payment and repayment confirmations.
Consortium or federated blockchain
This is an extension of the private blockchain in which responsibility for the blockchain is shared among several parties. For example, a group of persons or companies can share in the responsibility for verification of transactions and distribution of access rights.
A consortium blockchain is faster than the public type, but unlike a private blockchain, is not dependent on a single person or company. Since a number of participants are involved who must decide on the transactions to be performed, wrong decisions, fraud attempts and the like are also less likely to occur. Consortium blockchains are likewise suitable for companies and are used in the banking industry, for example. Here there are alliances of multiple companies.
Hornetsecurity News

Stay in touch

Sign up to get the latest News about Cloud Security.

Oops! We could not locate your form.

Within these alliances are what are known as ‘smart contracts’. Here a supplier, say, is automatically paid once he has supplied the correct quantity at the agreed time.

Use of blockchains in IT security

Blockchain technology can be used in a wide range of scenarios. In cyber security, the risk of cyberattacks can be minimized by means of secure encryption mechanisms. Data that has been verified in a consensus mechanism can then no longer be altered. The redundant infrastructure of a blockchain increases the failure safety of sensitive data and constantly increases user acceptance in the company.

More information:

 
High email security standard through SPF, DKIM and DMARC

High email security standard through SPF, DKIM and DMARC

Hornetsecurity offers secure protection against spyware and malware in email authentication through standardized sender reputation procedures.

Emails are still regarded as the most commonly used medium for the transmission of electronic messages. They are inexpensive, with unlimited distribution and offer the possibility of sending and receiving texts and file attachments in real time. Yet precisely these characteristics make email communication so vulnerable. Cyber criminals are constantly expanding their range of threats and developing new strategies to overcome security mechanisms. The authorization of permitted domains using a corresponding SPF record in the DNS zone is therefore no longer sufficient to successfully protect incoming email traffic from phishing and spam.
For this reason, Hornetsecurity’s email service has been expanded including further important sender reputation procedures in the fight against widespread attack patterns. In addition to SPF, procedures such as DKIM and DMARC are implemented against spam, spoofing, phishing and malware attacks as well as targeted CEO fraud attacks. Hornetsecurity has thus been applying the current recommendation for email security from the Federal Office for Information Security (BSI) and the Federal Association for IT Security (TeleTrusT) and thus offers a high security standard in email communication.

Secure from attacks with SPF, DKIM and DMARC

The SPF, DKIM and DMARC authentification procedures operate interconnected as a secure instrument to prevent from attacks on a company’s email communication. In the following, the used standards for sender and recipient reputation are presented and their functionalities are explained.

Sender-Policy-Framework (SPF) [RFC 7208]

SPF is a method by which unauthorized sender addresses of domains can be recognized and the delivery of their mails can be prevented. Authorized servers that are allowed to send emails in the name of a domain are entered in the so-called SPF record of the DNS zone. When an email is dispatched, the receiving server takes the sender domain from the envelope sender of an email and uses a DNS query to check whether the domain is registered in the SPF record. If the domain is not registered, the server is not authorized to send emails in the name of the domain. Emails from unauthorized servers, for example, can be classified as spam. Due to insufficient cryptographic security mechanisms that could ensure the senders authenticity, SPF should not be used as spam or phishing prevention. Despite successful SPF authentication, the sender ID of the envelope sender can be changed in the Body-From field, making it easy to manipulate the sender address.
Sender Policy Framework (SPF)

Domain-Keys-Identified-Mail (DKIM) [RFC 6376]

For a more comprehensive email protection, SPF can be usefully supplemented with DKIM. The main intention is to prevent spoofers from accessing sensitive data. As a special feature for email authentification, DKIM adds a digital signature with cryptographic encryption (SHA-256) to the email header. This signature operates as a kind of fingerprint and must have the same hash value in the checksum as calculated before sending. Any change to the data, no matter how small, would change the hash value and indicate an intervention in the message during transport.
To decrypt the signature, a key pair is needed which consists of a public key and a private key and is required for successful authorization of the sending server. The public key is entered as a TXT record in the DNS zone analog to the SPF entry. The secret key remains exclusively on the server that is authorized to send emails.
In the authorization procedure, the receiving server first determines the sender domain of the email and then checks for the name under which the matching public key can be found in the DNS zone of the sender domain. A successful signature check ensures that the decoded hash value corresponds to the original checksum before sending and that the email has not been modified during transmission.
Domain Keys Identified Mail (DKIM)

Domain-based Message-Authentification, Reporting and Conformance (DMARC) [RFC 7489]

A constant verification of the authenticity of emails cannot be guaranteed by SPF and DKIM on its own. This gap is closed by the DMARC test procedure, which complements the SPF and DKIM methods in their combined appearance to form a safe test procedure for sender reputation. DMARC ensures that the envelope sender address matches the body form address. This verification is important because traditional email programs only display the body-from information of an email and the actual sender information remains hidden.
DMARC also establishes certain guidelines for the SPF and DKIM procedures, which are stored in the TXT record of a DNS zone in form of requirements. These guidelines determine the instructions for the further handling of received emails. Thus for SPF the verification must be positive and the envelope sender address of the domain must match the address stored in the SPF record. For DKIM it is required that the signature is valid and that the domain matches the body-from address of the mail.
Domain Based Authentification Reporting and Conformance (DMARC)
If one or more requirements are not met, the check is negative and the email can be quarantined or rejected depending on the matrix.

DMARC offers the option to send reports in the versions of “Aggregated Reports” and “Failure Reports” (The reports may only be transmitted in compliance with the Federal Data Protection Act in the context of the detection and limitation of spam and phishing as well as for the protection of telecommunications systems and in accordance with the principle of proportionality. An authentication and verification system must be used to avoid misuse. ) The reports can help the domain administrator to keep track of his own email traffic and to check the DNS entries for syntactical correctness. Furthermore, the results can be used to support other systems. For example, the ZIP file of an undisputedly identified sender can be delivered without further effort, while for unidentified senders it is quarantined or rejected. This way, Hornetsecurity supports its own product Content Filter for fast and secure delivery of attachments in emails.

*The reports may only be transmitted in compliance with the Federal Data Protection Act in the context of the detection and limitation of spam and phishing as well as for the protection of telecommunications systems and in compliance with the principle of proportionality. An authentication and verification system must be used to avoid misuse.

Further technologies and encryption methods at a glance

  The so-called Domain Name System (DNS) is responsible for the connection with servers and can be used to convert host names into IP addresses. Sending and receiving messages to one or more recipients is made possible with the User Datagram Protocol (UDP). A connection between sender and receiver is not established and the data is delivered to the receiver without further control mechanisms. Therefore, even the sender is unable to determine whether his message has arrived successfully. Various security techniques such as TLS, DNSSEC and DANE are used to solve the security problem of outdated DNS. In the area of “secure email communication”, however, no standard has yet been able to establish itself. The latest standard is called MTA-STS and promises to successfully protect e-mails during transmission from electronic eavesdropping and manipulation.

Transport Layer Security (TLS) [RFC 5246 ]

TLS is a popular encryption protocol that has been developed further and standardized on the basis of the Secure Sockets Layer (SSL). The TLS protocol is used to ensure confidentiality, authenticity and integrity when transmitting data in insecure networks. The TLS protocol, divided into two levels, is a hybrid encryption method that uses both symmetric and asymmetric algorithms. It encrypts an end-to-end connection using symmetric algorithms. The TLS Handshake Protocol is based on the TLS Record Protocol and negotiates security parameters between sender and receiver. Connections to email servers can be initiated and encrypted via STARTTLS. TLS is used nowadays in many applications in which data, in particular access data, PINs and passwords can be transferred securely. These include applications such as e-commerce, home banking and e-government.

DNSSEC (Domain Name System Security Extensions)

[RFC 4035 ]

DNSSEC is an extension of DNS. It verifies the authenticity of the information stored in the DNS zone and ensures that an attacker cannot manipulate the DNS responses in his favour. With two different keys and a corresponding signature, the DNS data is protected. The recipient can verify the sender on the basis of the signatures used. If the signature is not valid, the DNS server of the provider blocks the response. DNSSEC cannot be applied to every domain and is therefore not commonly used.
Hornetsecurity News

Stay in touch

Sign up to get the latest News about Cloud Security.

Oops! We could not locate your form.

DNS-based Authentification of Named Entities (DANE) [RFC 6698]

The DANE protocol is another technique based on DNSSEC. This technique extends the basic protection of TLS connections by a cryptographic combination of certificates with DNS names. Thereby it should be verified whether an email server can establish and authenticate encrypted connections. This is to prevent a man-in-the-middle attack in which the message first reaches an attacker’s server. The DANE entry is stored in the DNS zone under a TLSA record which contains different characteristics of the respective TLS connection. These features define the certificate which a server must expect when connecting to the email service of the particular email server. For many domain administrators, however, DANE cannot be implemented since not every domain can be resolved via DNSSEC.

SMTP MTA Strict Transport Security (MTA-STS) [RFC 8461 ]

The connections between the servers so far are mostly unprotected. Thus, an important component for secure transport encryption is missing. This problem was apparently also recognized by large mailhosters such as Google, Microsoft and Verizon Media Company (Yahoo, AOL) as well as 1&1, which are participating in the development of the new MTA-STS standard. MTA-STS is intended to replace the often unrealisable DANE as well as the common STARTTLS, since attacks on the procedures cannot be excluded with absolute certainty. The new standard offers a similarly secure standard as DANE, but a much easier implementation than DNSSEC. For the implementation of the standard, email server operators can define a policy that can be retrieved by the sending mail transfer agent (MTA) using HTTPS [RFC2818]. The current version is displayed by a TXT data record in the Policy. In addition, these TXT data records contain an ID field which the sending MTA can use to check the temporarily stored policy for actuality without having to request an HTTPS connection. To find out if a receiver domain implements MTA-STS, the sender only needs to resolve a TXT dataset and identify the TXX record with the label “_mta-sts” (e.g. “_mta-sts.example.com”). The main difference to DANE and STARTTLS is that the results of DNS queries are stored in a cache so that manipulations by later connection attempts during the retention period are very likely to be detected.

Conclusion – Hornetsecurity offers highest email safety

Recent events show that widespread security protocols such as TLS by itself cannot guarantee safe connections between email servers. Previous improvements, such as DANE and DNSSEC, have so far not been applied worldwide, partly due to technical difficulties in implementation.
With standardized sender reputation procedures such as SPF, DKIM and DMARC, Hornetsecurity’s email service offers reliable protection against cyber attacks on email communication. The recommended standards of the BSI and TeleTrusT for secure email authentification have already been fully implemented and are successfully applied in the products of Hornetsecurity such as the spam filter and the content filter. For secure email communication, it is advisable to rely on the additional protection of content encryption using S/MIME (Secure / Multipurpose Internet Mail Extensions) or PGP (Open Pretty Good Privacy). The PKI-based email encryptions ensure the confidentiality of the transmitted messages between sender and recipient and protect the transferred data using cryptographic encryption methods. The Hornetsecurity encryption service offers this security solution directly in the cloud and thus completely secures the transmission process.
The new MTA-STS standard is supposed to provide better protection for the transmission process of emails with the help of already known techniques such as HTTPS and to provide methods for the detection of irregular access.
The ease of implementation and the rapid distribution are currently increasing the acceptance of this standard, which is currently being used by more and more mail administrators for its security potential.
CONTENT FILTER 2.0 – The security officer for your data transfer

CONTENT FILTER 2.0 – The security officer for your data transfer

The State Criminal Police Office of Lower Saxony is currently warning against an increase of emails with fraudulent application content. These emails are explicitly directed at companies with advertised vacancies and endanger in particular personnel departments that are involved in application processes. The seriously formulated emails are attached with alleged application documents in the form of archive data. If these files are unpacked, however, no application documents are revealed, but rather dangerous malware that infects the system.

Secure data transfer with Hornetsecurity’s Content Filter

With Hornetsecurity’s Content Filter, effective protection measures can be taken against unwanted file attachments. In addition to the general protection provided by the spam and virus filter, individual settings for attachments of incoming and outgoing emails can be made within the content filter. Updating the content filter to version 2.0 now also checks nested archives. Defined rules can still be applied for the entire domain or for certain user groups. This allows particularly vulnerable groups in the company to be deliberately protected against current attacks.

Easy setting – secure data transfer

The Content Filter offers an uncomplicated handling for the management of email attachments. Unwanted file formats, such as executable files, are grouped under the collective term .executable and can be selected from a predefined list with just a few clicks by the first time they are set up. Additional file formats that do not fall under one of the collective terms can be added if required. In addition, it is possible to individually configure the maximum permitted size for affected email attachments.
Hornetsecuity Content Filter 2.0

Fig. 1: Settings in the content filter for incoming emails

In case of application two actions can be set for handling the affected: Block email or cut attachment. In addition, encrypted Attachments, which are increasingly used in common formats such as PDF, ZIP, RAR etc., can be explicitly prohibited (Fig. 1). Furthermore, the content filter includes an automated comparison of file extensions with the supplied MIME type, which can differ significantly from the file extension in the case of suspicious email attachments. Archive Files that have internal nesting structures in the form of additional archives are analyzed and evaluated down to the security-relevant level.
If the content filter intervenes and removes a suspicious attachment, it changes the original state of the message. For signed emails, active intervention by the content filter causes the signature to be corrupted. If this occurs, the content filter informs the recipient and specifies whether the signature was valid before the change (Fig.2).
Hornetsecurity Content Filter 2.0

Fig. 2: Valid signature after truncating the content

However, if the certificate of the signed email is available on our systems, the email whose signature was broken by truncating the file attachment is re-signed and thus retains its validity.
The content filter can be activated for all Hornetsecurity partners and customers in addition to the spam and virus filter.

ATP – the interoperable complement for comprehensive protection

The current threat landscape of malware ranges from ransomware to cryptominers and is constantly changing. Spam, virus and content filters provide a solid basis against cyber attacks. These filters do not provide 100% protection against targeted and sophisticated attacks on companies. Further protection mechanisms are needed that adapt to the constantly changing types of attacks and malware. By combining Hornetsecurity’s interoperable filters, full protection against specific cyber attacks can be achieved and sustainably secured for companies.
In addition to the spam and virus filter, Advanced Threat Protection (ATP) from Hornetsecurity offers reliable protection against current malware attacks. ATP integrates seamlessly into the existing filters from Hornetsecurity email services and has, in comparison to the content filter, profound behavior analyses of file contents. Thanks to the integrated ATP engines such as the sandbox, URL Rewriting and URL Scanning , attacks such as targeted or blended attacks are detected early and the necessary protective measures are initiated in real time. For example, hidden links infiltrated in files can be recursively tracked in an isolated environment and the content hidden within can be subjected to forensic analysis. For content patterns that indicate malicious intent, the company’s IT security team is notified in real time for immediate protection.
Email encryption – A guide for implementation at SMBs

Email encryption – A guide for implementation at SMBs

Certificates, signed emails, symmetric and asymmetric encryption, S/MIME, TLS and PGP – for many who do not regularly deal with email encryption these terms are quite foreign. However, with the new basic data protection regulations (DSGVO) these terms have been pushed to the top of the to-do lists for many SMBs. Although, many companies lack the necessary knowledge to implement the new requirements in regards to the encryption of their email communication. In this article, Hornetsecurity aims to explain some of the basic terms and technologies around email encryption.

Asymmetric and symmetric email encryption – what are the differences?

If you take a closer look at asymmetric and symmetric email encryption you will very quickly discover that these two are fundamentally different. Essentially, they differ in the number and type of keys used.
Symmetric email encryption uses the same key to encrypt and decrypt the email. This means that the sender and recipient of an email share the same key. Thus, this procedure is very simple, but its security is essentially tied to the secrecy of the keys – if the key falls into the hands of a third party that person can decrypt the entire communication.
Asymmetric email encryption uses a total of four keys, one key pair each – a public and a private key per communication partner. The public key is accessible to everyone who wants to communicate and is transferred with the certificate exchange. It is used to encrypt the data, in our case, emails.
To decrypt the encrypted data again, the private key belonging to the public key is required. Although the key pair is mathematically interdependent and it’s practically impossible to calculate it.

S/MIME, PGP and TLS – what are the abbreviations?

PGP and S/MIME are asymmetric encryption methods. Both procedures have a decisive advantage and disadvantage. The advantage is that the email provider of the sender and recipient also has no insight into the email. The disadvantage is that only the message is encrypted. The sender and recipient as well as the subject can still be read.
The main difference between email encryption with S/MIME and PGP is the issue of certificates. While PGP (also known as OpenPGP) is an open source solution in which everyone can create their own certificates, certification at S/MIME takes place via official certification authorities, the so-called Certificate Authorities (CA).
TLS differs fundamentally from email encryption with S/MIME or PGP. Here it’s not the email itself that is encrypted, but only the connection between the two communicating servers. This means that the email cannot be accessed during transport, but it is not encrypted on the respective mail servers.

How to implement email encryption – there is no “one” way

All roads lead to Rome – but which ones lead to legally compliant email encryption? In fact, there are several ways for companies to implement legally compliant email encryption. The most prominent are on-premise and cloud-based solutions.
With on-premise solutions, the emails are encrypted directly on site, i.e. at the companies themselves. The email encryption software can be purchased, rented or operated completely independently from an external provider. Although this procedure offers the company a high degree of transparency and decision-making freedom, it involves an administrative effort that should not be underestimated. The costs for maintenance and operation are also quite significant. Today, on-premise solutions are considered a thing of the past and are increasingly being replaced by modern cloud-based computing.
With the cloud-based computing alternative, also known as “Software as a Service” (SaaS) solution, the security provider relieves the company of all expenses, such as administrative and operational costs. All of the company’s email traffic is then handled by the security provider’s servers, including Hornetsecurity’s email encryption service. The route between the customer’s mail server and the service provider is protected by TLS. This solution is characterized by the elimination of administrative work for any particular company. However, to fully ensure secure email communication, TLS and S/MIME can and should be used simultaneously. This is the only way to encrypt the email itself and its transport route.

Weiterführende Informationen:

Hornetsecurity signs first U.S. distributor deal

Hornetsecurity signs first U.S. distributor deal

Value-added distributor Contronex includes Hornetsecurity’s Cloud Security Services into its portfolio   Hornetsecurity has closed its first VAD contract in the U.S. with Naples, FL based distributor Contronex.  With this new partnership, Hornetsecurity will significantly expand its reach into the U.S. and Canada.
Hornetsecurity News

Stay in touch

Sign up to get the latest News about Cloud Security.

Oops! We could not locate your form.

  According to Oliver Dehning, CEO of Hornetsecurity. “With Contronex, we have found the perfect match. They are experienced in providing the best security solutions in the IT marketplace.  Also, they offer an extensive network of resellers that are trained in selling high-class security products. We’re very happy to have established a relationship with this experienced partner.”   “As a growing value-added distributor of IT security software solutions, we regularly add new vendors to expand our product portfolio. With Hornetsecurity, the onboarding process was accomplished quicker than ever”, adds Beat Kramer, CEO at Contronex.   Hornetsecurity, a leading European Cloud Security Service provider, offers a full suite of Email Security Solutions protecting companies of all sizes from malware or phishing attacks and unauthorized access and loss of data, all without the need for extra hardware, software or administrative effort.
Founded in 1990 in Naples, FL, Contronex specializes in the distribution of IT security solutions and commits to three simple concepts: integrity, reliability and commitment to service, which aligns perfectly with the Hornetsecurity approach. Contronex has developed a unique partner program for resellers and managed service providers that helps them to purchase the products their clients’ need.