Blue

This short article discusses the potential friction between various layers of e-mail protection.

Active and Passive Email Protection

Email protection is one of the most important component of the organization’s general defence structure as the overwhelming number of cyber attacks still begins with an email. There is obviously a constant evolution in technology, but the main course is more or less the same. Some social engineering spiced up with compromised email accounts and domain impersonation. It is irrelevant what types of email defences are considered as “active” or “passive” protection, whether technical or user-related, but one thing is for sure that both must be enforced to secure an organization’s email perimeter properly. I classify all technicals as “passive” because there is no user interaction. This could include the most common e-mail security protocols, like Transport Layer Security (TLS), Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), Domain-Based Message Authentication, Reporting & Conformance (DMARC). Also different end-to-end encryption protocols like Secure/Multipurpose Internet Mail Extensions (S/MIME), Pretty Good Privacy (PGP) or Secure Email Gateways (SEG) belong to here to combat spam, malware and more common phishing campaigns by using blacklists of known malicious signatures, web addresses and email domains. The “active” ones are more user related ones like the shaping of user interactions with constant training to Identify Threats and potential user manipulation techniques.

Interaction

Let’s start with the training part, shall we.. Well, there is nothing more useful than actually sending out fake malicious emails to the users across the board. With regular internal phishing campaigns users’ vigilance not only can be statistically measured but also, they could get a real-life experience of how these emails look, which is especially helpful for new joiners.

The email delivered as part of the simulation is about a PDF document download with the file attached as well. Red flags are highlighted to assist in identifying the vulnerabilities to which the email relates.

The email tracked as an example succeeded in going through multiple levels of defense.

Unfortunately though it was caught by one of them..

This essentially means that the awareness campaign was unsuccessful, as for a large organization with thousands of accounts there is no ability to track all the emails let alone addressing the issues individually. This is a good example of why all layers of protection need to be properly tested and harmonized, as the security of confidential information is at stake.

Thanks for reading and as always, any feedback is most welcome.

This short piece talks about email protection with some lab examples and how analyzing inbound email traffic could be helpful in defending an organization.

Analyzing emails

It is not easy to monitor the flow of inbound email traffic for a medium or large organization on an ongoing basis. Emails pass through several layers of protection gateways, but still, the number of emails landing in user accounts is huge. Suspicious emails can be classified in a number of ways but the most obvious option is severity. Malicious emails can be put in the category of phishing emails that also integrates all the necessary social engineering for it. On top of all the automation available today manual controls are always necessary. A very good approach is to enable users to report suspicious emails to the information security team to get potentially malicious emails analyzed by them and possibly take action in case of incidents.

Investigation

The sender does not look like malicious and would have been blocked anyway if it was, but it must always be verified. Usually it is not the sender’s domain to be blocked because many legitimate email domains are used for that purpose. Well, for instance, we have an attachment here that is best reviewed.

Virustotal and some other scanners show no threats, so let’s open the file in a text editor to check what’s inside.

Ok, so there is a suspicious URL in it which is better to get scanned.

Whois records justify our suspicion that this could be malicious or to be used for malicious purposes by evil actors as it is a newly registered domain.

After all our discoveries, it is better to block the domain completely. The Top Level Domain (TLD) could also be blocked, but for the time being it is enough.

Thanks for reading and as always, any feedback is most welcome.

This is another short piece of the “Strictly Theoretical” mini series in which I put insensible historical incident management and suspicious behaviour patterns under the microscope reflecting on how the “inner” and “outer” world continuously interact with each other forming the everyday life of the production environment.

Malicious Excel Document

Quite often, users in different departments receive external emails with attachments containing client data or other information. By the time the email lands in the recipients’ email account, it has gone through different gateways, filters, virus checks, but still there can be ambiquous data in it. Adversaries can attempt to obscure malicious code by abusing how rundll32.exe loads DLL function names. This is what can happen when from an Excel or Word document when a supposedly harmless button or macro invokes a function that could start a connection back to the attacking machine.

What needs to be done

In a situation like this immediate action must be taken. First, the user must confirm through a separate channel if they have interacted with that specific document. Second, according to the responses, the machine needs to be quarantined and re-imaged, user sessions need to be forced offline with password reset.

Thanks for reading and as always, any feedback is most welcome.