SQLite forensic's notes
This is how you defend against Phishing
From field of the message that is owned by the organization they are impersonating.
There are ways to prevent spammers and phishers from spoofing your domain. Email authentication – verify that an email really comes from the domain it claims to come from – is based on widely-accepted standards, well documented in our article. These security mechanisms are relatively easy to set up and offer a good level of protection.
If these methods almost completely block spam, why are we still hearing about them widely? In practice, not all companies implement them.
DMARC provides three main elements to the previously existing email authentication standards:
Like any protection, these too are an additional problem to solve for the proper functioning of the system: Broadly speaking, the owner of the domain decides what the recipient will do with the emails received in his name.
There is no quick and safe way to test whether a configuration works or not, without involving several parties at the same time. This makes everything more academic: You have to sit in front of a paper and design the policy so that it can theoretically work; once implemented, you must monitor its actual functioning and react to any problem.
The protection systems mentioned are difficult to understand and implement for a common IT department, because:
Besides, there are some specific technical criticalities:
This explains, in part, why many administrators prefer to avoid its implementation or implement it “Pro-forma”.
To find out what is the implementation state in the various companies that communicate daily with millions of users, we tried to do a sample analysis of domains that we think are interesting. The list of domains is provided by OpenPage Rank, we have selected the domains (based on TLDs, keywords, etc.), analyzed the public DNS records, and assigned a security score to the various policies found.
The analysis of the records includes both the identification of the mechanisms present (SPF, DKIM, DMARC) and the defined policies.
In policy analysis:
-no point is subtracted
The information collected is stored in a MongoDB for analysis:
We analyzed 414783 domains, selected by specific top-level-domains:
|TDL||Number of Domains|
The following figure shows how many domains, in total and grouped by selected TLDs, are implementing protection mechanisms.
The next figure illustrates in detail for each TDL the percentage of domains using protection mechanisms.
The next figure shows the distribution of domains per security level range.
The security level is calculated based on the presence of the protection mechanisms and how good is configured.
|.-100 to -50||The security policy does not use the security settings or uses them incorrectly|
|.-49 to 0||The security policy presents options that lead to an insecure result|
|.1 to 50||The security policy could be more restricted|
|.51 to 100||The security policy is well configured|
We now take a closer look at two specific SPF mechanisms (all and ip4_prefix), to show the creativity of some administrators with SPF policies.
This shows how the most important mechanism of the SPF policy, the all, is configured across the analyzed domains. This mechanism indicates what to do with the non-compliant emails (drop, tag, or ignore). This mechanism is mandatory.
This is a good example of what can go wrong:
"v=spf1 +all" is a valid SPF policy, but as stated by SPF organization, The domain owner thinks that SPF is useless and/or doesn’t care.
The figure shows the configuration of another SPF mechanism, the ip4. This mechanism is used to mark a certain number of servers as valid mail servers for the domain. We extracted the mask to calculate how many servers are whitelisted with this mechanism. The number of those servers should be limited to the mail servers only. Note, that this mechanism is optional.
v=spf1 mx a ip4:22.214.171.124/2 ip4:126.96.36.199/2)
There are eight mechanisms analyzed for the SPF. We have shown only two in detail, to emphasize that even the presence of the SPF policy is not a guarantee of safety. Furthermore, the intentions of those who configure an ip4 prefix to 0 are always, at least, rummy.
Systems to protect against identity theft exists for many years, but for various reasons, they are not yet used on a large scale and are often used only in an informational mode.
Our research shows how the implementation of such systems, even for sensitive domains, is still far from complete.
Let our Red Team conduct a professional social engineering test!
Our experts will get in contact with you!
Further articles available here