Most reliable IT solutions provider
Case Studies \ Preventing Financial Fraud - Securing Email
With advent of digital information, communication has become blazing fast; and so has risen the opportunity for online fraud.
Many organizations have fallen victim to digital impersonation of key individuals. These “identities” are obtained using various approaches, the most common of them being – Phishing.
By phishing, an impersonator obtains sensitive information with the intent to use that information for illegitimate gains. The success of a phishing attack requires establishing trust with the victim. Attackers use various techniques to gain this trust:
Following are noteworthy excerpts from articles that highlight the extent of financial damage these frauds are causing:
“On a global scale, this translates to losses of approximately $3.7 trillion, according to anti-fraud experts.
Small Companies Suffer Greater Monetary Losses
While both large and small organizations fall victim to occupational fraud, the ACFE found that companies with fewer than 100 employees are particularly vulnerable compared to their larger counterparts.”
“Fifteen percent of respondents, who had a breach or compromise, estimated the cost of that breach at between $500,000 and a $1 million, with 6% putting the figure at $5 million or more.”
Thankfully, using a few techniques, such as setting up SPF, DKIM and DMARC (detailed at the end of the study), the risks associated with malicious actors, that use email to perpetrate these types of fraud, can almost be eliminated.
Combating Digital Fraud should be approached from two fronts:
Since this fighting email fraud is restrictive in nature, it does present a situation where legitimate emails from business partners with improperly configured email systems might be bounced.
Also, the proposed technical solutions are apt in flagging emails originating from non-authorized sources; the end user still needs to be trained to be vigilant of impersonators that may send emails from addresses similar to the impersonated account. These emails may be technically setup to be authorized and may appear authentic due to the similarity in the addresses.
e.g. [email protected] and [email protected]
Notice the difference in the domain name?
Here is an actual email sent by fraudster in an attempt to trick them to transfer funds. To maintain privacy we’ve starred and scrambled information:
This one in particular was a good example of identifying both sender and receiver, which increases the probability of successful attack manifolds.
Preventive Methods – Administrative Controls
Most of us would agree that it is a technological problem, which requires a technological solution. So following are ways through which an organization can combat and minimize the risk outsiders pretending to be them:
Cloud providers:v=spf1 include:spf.protection.outlook.com include:argustech.com ~all
Own Mail server:v=spf1 a ip4:188.8.131.52/28 include:argustech.com ~all
ArgusTech SPF record: v=spf1 include:spf.protection.outlook.com IP184.108.40.206 ip220.127.116.11 ~all
|v||version||spf1||The SPF record version|
|+||include||spf.protection.outlook.com||Pass||The specified domain is searched for an ‘allow’.|
|+||ip4||18.104.22.168||Pass||Match if IP is in the given range|
|+||ip4||22.214.171.124||Pass||Match if IP is in the given range|
|~||all||SoftFail||Always matches. It goes at the end of your record.|
e.g DKIM record for Example – domain: Example.com Selector=google
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCM0eH9rBGDF8ceRkisetzgtzxLZYLlW64KUB1B45rWh/xyc4UiycNHZL1crse1uQYhP14+UA+hTOI+h/H+
|v||dkim1||version||The DKIM record version|
|k||rsa||Key type||The type of the key used by tag (p).|
|Public Key||Public-key data. The syntax and semantic|
s of this tag value before being encoded
in base64 are defined by the (k) tag.
A selector is added to the domain name, used to find DKIM public key information. It is specified as an attribute for a DKIM signature, and is recorded in the DKIM-Signature header field. Validation uses the selector as an additional name component, to give differential DNS query names.
How DMARC Works:
DMARC policies are retrieved by the mail-receiving organization during a SMTP session, via DNS. When mail receivers query DNS, they look for a DMARC TXT record at the DNS domain that matches the one found in the RFC5322. From domain in the email message. If a policy is found, that policy is combined with the author’s domain and the SPF and DKIM results to deliver a DMARC policy result. This policy result will be either “pass” or “fail” and may cause a report to be generated. If a policy is not found, the DMARC module determines the organizational domain and repeats the attempt to retrieve a policy from the DNS
e.g. DMARC record at Example.com:
v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];ruf=mailto:[email protected]
|v||dmarc1||version||The DMARC record version|
|p||quarantine||Policy||Policy to apply to email that fails the DMARC test. TagValue can be ‘none’, ‘quarantine’, or ‘reject’.|
|pct||100||Percentage||The percentage tag tells receivers to only apply policy against email that fails the DMARC check X amount of the time.|
|rua||mailto:[email protected];ruf=mailto:[email protected]||Receivers||List of URIs for receivers to send XML feedback to. URIs are required to be added in the format of ‘mailto:[email protected]’.|
FCrDNS testFCrDNS, or Forward Confirmed reverse DNS, is when an IP address has forward and reverse DNS entries that match each other. For FCrDNS verification, first a reverse DNS lookup is done to get a list of PTR. Then for each domain name mentioned in the PTR records, a regular DNS lookup is done to see if any of the A records match the original IP address. If there is a forward DNS lookup that confirms one of the names given by the reverse DNS lookup, then the FCrDNS check passes.
IP address 126.96.36.199 resolves to mail.example.com.
Host name mail.example.com resolves to IP addresses 188.8.131.52 and 184.108.40.206.
Thus, reverse DNS for IP address 220.127.116.11 is forward confirmed.