Preventing Financial Fraud – Securing Email
Digital Fraud – the challenge
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 the phishing attack requires establishing trust with the victim. Attackers use various techniques to gain this trust:
- Socially engineered spoofing via email to request information or process financial transactions
- Sharing malicious attachments (Trojans) that give access to computers to obtain sensitive information
- Email links that take a victim to a website (with legitimate appearance) that requests the victim to enter targeted information
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.”
Digital Fraud – can we fight it?
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:
- Training the workforce to be able to identify possible attempts of Socially Engineered attacks
- Deploy technical gates that screen and block emails NOT originating from authorized sources
Certain points to be aware of:
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.
Digital Fraud – how to secure your organization
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
- Reduce Public Fingerprints: In the above example fraudster have increased the chances of successful attack manifolds because he has properly identified both the sender and receiver, their roles and responsibilities in an organization, and their professional hierarchy. Websites like ZoomInfo.com and Connect.Data.com, indirectly help these email spoofers to preciously identify their targets. Organizations need to weigh benefits versus risk for maintaining company information on these portals.
- Security Awareness Training: When it comes to IT security weakest link in the chain is humans. Users should be made aware on aspect of security including social engineering tactics deployed by email spoofers. It should be conducted every quarter or at least half yearly.
Preventive Methods – Technical 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:
- Sender Policy Framework (SPF): SPF is implemented by adding a SPF record on the DNS server. The SPF record contains (all) the IP address / domain names that a receiver may expect to receive emails from:
Cloud providers:v=spf1 include:spf.protection.outlook.com include:argustech.com ~all
Own Mail server:v=spf1 a ip4:126.96.36.199/28 include:argustech.com ~all
ArgusTech SPF record: v=spf1 include:spf.protection.outlook.com IP188.8.131.52 ip184.108.40.206 ~all
|v||version||spf1||The SPF record version|
|+||include||spf.protection.outlook.com||Pass||The specified domain is searched for an ‘allow’.|
|+||ip4||220.127.116.11||Pass||Match if IP is in the given range|
|+||ip4||18.104.22.168||Pass||Match if IP is in the given range|
|~||all||SoftFail||Always matches. It goes at the end of your record.|
- DomainKeys Identified Mails (DKIM): is a domain level digital signature authentication framework. A DKIM record is a component of a system that allows your server to cryptographically sign your email messages so that recipients can, if they like, confirm that a message came from you.
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.
- Domain-based Message Authentication, Reporting and Conformance (DMARC): is a mechanism for improving mail handling by mail-receiving organizations.
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||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]’.|
- rDNS & FCrDNS: While receiving an email message, a mail server may try to attempt reverse DNS lookup. If the lookup fails (no PTR record), the message may be marked as spam or rejected.
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 22.214.171.124 resolves to mail.example.com.
Host name mail.example.com resolves to IP addresses 126.96.36.199 and 188.8.131.52.
Thus, reverse DNS for IP address 184.108.40.206 is forward confirmed.