U.S. patent application number 14/861846 was filed with the patent office on 2017-03-23 for detecting and thwarting spear phishing attacks in electronic messages.
The applicant listed for this patent is Vade Retro Technology Inc.. Invention is credited to Sebastien GOUTAL.
Application Number | 20170085584 14/861846 |
Document ID | / |
Family ID | 55962778 |
Filed Date | 2017-03-23 |
United States Patent
Application |
20170085584 |
Kind Code |
A1 |
GOUTAL; Sebastien |
March 23, 2017 |
DETECTING AND THWARTING SPEAR PHISHING ATTACKS IN ELECTRONIC
MESSAGES
Abstract
A computer-implemented method may comprise receiving an
electronic message from a purported known sender; accessing a
database of known senders and determining whether the sender
matches one of the known senders. The degree of similarity of the
sender to at least one of the known senders may then be quantified.
The received message may then be determined to be legitimate when
the purported known sender is determined to match one of the known
senders. The received electronic message may be flagged as being
suspect when the purported known sender does not match one of the
plurality of known senders and the quantified degree of similarity
of the purported known sender to one of the known senders is
greater than a threshold value. A perceptible cue may then be
generated when the received message has been flagged as being
suspect, to alert the recipient that the flagged message is likely
illegitimate.
Inventors: |
GOUTAL; Sebastien; (CYSOING,
FR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Vade Retro Technology Inc. |
San Francisco |
CA |
US |
|
|
Family ID: |
55962778 |
Appl. No.: |
14/861846 |
Filed: |
September 22, 2015 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06N 20/00 20190101;
H04L 51/12 20130101; H04L 67/02 20130101; H04L 63/1483 20130101;
H04L 63/1425 20130101; G06N 7/005 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; G06F 17/30 20060101 G06F017/30 |
Claims
1. A computer-implemented method, comprising: receiving an
electronic message from a purported known sender over a computer
network; accessing a database configured to store a plurality of
known senders of electronic messages and determining whether the
purported known sender of the electronic message matches one of the
plurality of known senders of electronic messages in the database
of known senders; quantifying a degree of similarity of the
purported known sender of the electronic message to at least one of
the plurality of known senders of electronic messages stored in the
database; determining the received electronic message to be
legitimate when the purported known sender is determined to match
one of the plurality of known senders in the database of known
senders; flagging the received electronic message as being suspect
when: the purported known sender does not match one of the
plurality of known senders in the database of known senders; and
the quantified degree of similarity of the purported known sender
of the electronic message to one of the plurality of known senders
of electronic messages is greater than a threshold value; and
generating at least a visual cue when the received electronic
message has been flagged as being suspect, to alert a recipient
thereof that the flagged electronic message is likely
illegitimate.
2. The computer-implemented method of claim 1, wherein the
electronic message comprises an email.
3. The computer-implemented method of claim 1, wherein quantifying
comprises calculating a string metric of a difference between the
purported sender and one of the plurality of known senders in the
database of known senders.
4. The computer-implemented method of claim 1, wherein quantifying
comprises calculating a Levenshtein distance between the purported
sender and one of the plurality of known senders in the database of
known senders.
5. The computer-implemented method of claim 1, further comprising
prompting for a decision confirming the flagged electronic message
is suspect or a decision denying that the flagged electronic
message is suspect.
6. The computer-implemented method of claim 5, further comprising
dropping the flagged electronic message when the prompted decision
is to confirm that the flagged electronic message is suspect and
delivering the flagged electronic message when the prompted
decision is to deny that the flagged electronic message is
suspect.
7. The computer-implemented method of claim 1, wherein accessing
also accesses a database of blacklisted senders of electronic
messages and dropping the received electronic message if a sender
of the received electronic matches an entry in the database of
blacklisted senders of electronic messages.
8. A computing device configured to determine whether a received
electronic message comprises a spear phishing attack, comprising:
at least one processor; at least one data storage device coupled to
the at least one processor; a plurality of processes spawned by
said at least one processor, the processes including processing
logic for: receiving an electronic message from a purported known
sender over a computer network; accessing a database configured to
store a plurality of known senders of electronic messages and
determining whether the purported known sender of the electronic
message matches one of the plurality of known senders of electronic
messages in the database of known senders; quantifying a degree of
similarity of the purported known sender of the electronic message
to at least one of the plurality of known senders of electronic
messages stored in the database; determining the received
electronic message to be legitimate when the purported known sender
is determined to match one of the plurality of known senders in the
database of known senders; flagging the received electronic message
as being suspect when: the purported known sender does not match
one of the plurality of known senders in the database of known
senders; and the quantified degree of similarity of the purported
known sender of the electronic message to one of the plurality of
known senders of electronic messages is greater than a threshold
value; and generating at least a visual cue when the received
electronic message has been flagged as being suspect, to alert a
recipient thereof that the flagged electronic message is likely
illegitimate
9. The computing device of claim 8, wherein the electronic message
comprises an email.
10. The computing device of claim 8, wherein quantifying comprises
calculating a string metric of a difference between the purported
sender and one of the plurality of known senders in the database of
known senders.
11. The computing device of claim 8, wherein quantifying comprises
calculating a Levenshtein distance between the purported sender and
one of the plurality of known senders in the database of known
senders.
12. The computing device of claim 8, wherein the processes further
comprise processing logic for prompting for a decision confirming
the flagged electronic message is suspect or a decision denying
that the flagged electronic message is suspect.
13. The computing device of claim 12, wherein the processes further
comprise processing logic for dropping the flagged electronic
message when the prompted decision is to confirm that the flagged
electronic message is suspect and for delivering the flagged
electronic message when the prompted decision is to deny that the
flagged electronic message is suspect.
14. The computing device of claim 8, wherein the processes further
comprise processing logic for accessing a database of blacklisted
senders of electronic messages and dropping the received electronic
message if a sender of the received electronic matches an entry in
the database of blacklisted senders of electronic messages.
15. A tangible, non-transitory machine-readable data storage device
having data stored thereon representing sequences of instructions
which, when executed by a computing device, cause the computing
device to: receive an electronic message from a purported known
sender over a computer network; access a database configured to
store a plurality of known senders of electronic messages and
determine whether the purported known sender of the electronic
message matches one of the plurality of known senders of electronic
messages in the database of known senders; quantify a degree of
similarity of the purported known sender of the electronic message
to at least one of the plurality of known senders of electronic
messages stored in the database; determine the received electronic
message to be legitimate when the purported known sender is
determined to match one of the plurality of known senders in the
database of known senders; flag the received electronic message as
being suspect when: the purported known sender does not match one
of the plurality of known senders in the database of known senders;
and the quantified degree of similarity of the purported known
sender of the electronic message to one of the plurality of known
senders of electronic messages is greater than a threshold value;
and generate at least a visual cue when the received electronic
message has been flagged as being suspect, to alert a recipient
thereof that the flagged electronic message is likely
illegitimate.
16. The tangible, non-transitory machine-readable data storage
device of claim 15, wherein the electronic message comprises an
email.
17. The tangible, non-transitory machine-readable data storage
device of claim 15, wherein quantifying comprises calculating a
string metric of a difference between the purported sender and one
of the plurality of known senders in the database of known
senders.
18. The tangible, non-transitory machine-readable data storage
device of claim 15, wherein quantifying comprises calculating a
Levenshtein distance between the purported sender and one of the
plurality of known senders in the database of known senders.
19. The tangible, non-transitory machine-readable data storage
device of claim 15, wherein the stored sequences of instructions
further comprise prompting for a decision confirming the flagged
electronic message is suspect or a decision denying that the
flagged electronic message is suspect.
20. The tangible, non-transitory machine-readable data storage
device of claim 15, wherein the stored sequences of instructions
further comprise dropping the flagged electronic message when the
prompted decision is to confirm that the flagged electronic message
is suspect and delivering the flagged electronic message when the
prompted decision is to deny that the flagged electronic message is
suspect.
21. The tangible, non-transitory machine-readable data storage
device of claim 15, wherein the stored sequences of instructions
further comprise accessing a database of blacklisted senders of
electronic messages and dropping the received electronic message if
a sender of the received electronic matches an entry in the
database of blacklisted senders of electronic messages.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is related in subject matter to
commonly-owned and co-pending U.S. patent application Ser. No.
14/542,939 filed on Nov. 17, 2014 entitled "Methods and Systems for
Phishing Detection", which is incorporated herein by reference in
its entirety.
BACKGROUND
[0002] A spear phishing email is an email that appears to be from a
known person or entity. But it is not. The spear phisher often
knows the recipient victim's name, address, job title and
professional network. The spear phisher knows a lot about his
intended victim, thanks to the quantity and rich variety of
information available publicly through online sources, the media
and social networks.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] FIG. 1 is a table showing examples of legitimate email
address and spoofed email addresses.
[0004] FIG. 2 is a table showing legitimate email address, spoofed
email addresses and a calculated string metric (e.g., a Levenshtein
distance) between the two, according to one embodiment.
[0005] FIG. 3 is a flow chart of a method according to one
embodiment.
[0006] FIG. 4 is a system configured according to one
embodiment.
[0007] FIG. 5 is a block diagram of a computing device configured
according to one embodiment.
DETAILED DESCRIPTION
[0008] Spear phishing is a growing threat. Spear phishing is,
however, very different from a phishing attack. The differences
between a phishing attack and a spear phishing attack may include
the following: [0009] The target of a spear phishing attack is
usually a member of the corporate market, and especially people who
have access to sensitive resources of the company. Typical targets
are accountants, lawyers and top management executives. In
contrast, phishing attacks tend to target all end users more
indiscriminately. [0010] Most often, a spear phishing attack is
initiated only after a thorough analysis of the target victim. This
analysis is aided by the great amount of personal and professional
information available on social networks (including, for example,
Facebook, Twitter, LinkedIn and the like), company website and
other media. Consequently, a spear phishing attack is often crafted
to be unique to the targeted individual. Phishing attacks, on the
other hand, tend to be somewhat more indiscriminate, typically
targeting thousands of people. [0011] In the first phase of a spear
phishing attack, the email purports to originate from a well-known
(to the targeted victim) and trusted individual, such as a
coworker. In contrast, phishing emails typically appear to
originate from a trusted company (PayPal, Dropbox, Apple, Google,
etc.). [0012] The second phase of spear phishing attack has a
different modus operandi: a malicious attachment or a malicious
Uniform Resource Locator (URL) that leads the victim to install
malware that will perform malicious operations (e.g., theft of
data). Alternatively, the spear phishing email may contain text in
the body of the email that induces or dupes the victim to perform a
predetermined action (e.g., send a wire transfer, disclose
sensitive information or the like). Instead, phishing attacks
typically rely on the inclusion of a malicious URL only.
[0013] According to one embodiment, to protect a user from a spear
phishing attack, a protection layer may be applied for each phase
of the spear phishing attack. That is, during the first phase of
the spear phishing attach, one embodiment detects whether an
impersonation of a known sender is likely. During the second phase
of the spear phishing attack, a detection procedure may be carried
out, to determine whether the suspicious email may contain a
malicious attachment, a malicious URL or contains suspect text in
the body of the email.
[0014] According to one embodiment, to detect whether an email
constitutes a potential spear phishing attack, the "From" email
address (the sender's email address) may be scrutinized to detect
whether the sender is a legitimate, known and trusted entity or is
potentially an impersonation of the same. According to one
embodiment, if a user receives an email from an unknown recipient,
a check may be carried out to determine if the sender's email
address is a known contact of the email recipient. If the sender's
email address looks like but is in any way different from a known
contact of the recipient, the email recipient may be warned
(through the generation of a visual and/or audio cue, for example)
that the email is at least potentially illegitimate, as
impersonating a known contact--the essence of a spear phishing
attack.
[0015] One embodiment is configured to protect the user (e.g., an
email recipient) by carrying out activities including: [0016] 1.
Managing, for the protected user, a list of his or known email
contacts called KNOWN_CONTACTS; [0017] 2. Managing, for the
protected user, a list of blacklisted email contacts called
BLACKLIST; [0018] 3. Checking each incoming email to determine
whether the sender email address looks like the email address of a
known email contact; and [0019] 4. Warning the end user if an
incoming email is determined to be potentially illegitimate.
[0020] FIG. 1 is a table showing examples of legitimate email
address and spoofed email addresses, to email address
impersonation. As shown, the legitimate email address is
john.smith@gmail.com. In the first row, the legitimate
joh.smith@gmail.com has been spoofed by replacing the domain
"gmail.com" with "mail.com". In the second row, "gmail.com" has
been replaced with another legitimate domain; namely, "yahoo.com".
Indeed, the user may not remember whether John Smith's email is
with gmail.com, mail.com or yahoo.com, and may lead the user to
believe that the email is genuine when, in fact, it is not. In the
third row, the period between "john" and "smith" has been replaced
by an underscore which may appear, to the user, to be a wholly
legitimate email address. The fourth row shows another variation,
in which the period between "john" and "smith" has been removed,
which change may not be immediately apparent to the user, who may
open the email believing it originated from a trusted source (in
this case, john.smith@gmail.com). In the fifth row, an extra "t"
has been added to "smith" such that the email address is
john.smitth@gmail.com, which small change may not be noticed by the
user. Lastly, the sixth row exploits the fact that some letters
look similar, such as a "t" and an "l", which allows an
illegitimate email address of johnsmilh@gmail.com to appear
legitimate to the casual eye.
[0021] Managing List of Known Email Contacts
[0022] According to one embodiment, a list of his known email
contacts called KNOWN CONTACTS may be created and maintained. All
email addresses in this list may be stored in lowercase. According
to one embodiment, the KNOWN_CONTACTS list may be initially seeded
by the protected user's address book. According to one embodiment,
the protected user's address book, for performance and accuracy
reasons, may not be used if it exceeds a predetermined (say 1,000,
for example) maximum number of entries. This predetermined maximum
number of entries may be represented by an ADDRESS_BOOK_MAX_SIZE
variable (whose default value may be set a 1,000). Very large
address books may, for example, be associated with very large
companies that share the whole company address book with all
employees.
[0023] Another source of legitimate email address to populate the
KNOWN_CONTACTS list are email addresses of emails received by the
end user, with the exception of automated emails such as email
alerts, newsletters, advertisements or any email that has been sent
by an automated process. The email addresses of people to whom the
end user has sent an email is also another source of legitimate
email addresses. According to one embodiment, KNOWN_CONTACTS may be
updated in one or more of the following cases: [0024] When the
address book is updated; [0025] When the protected user receives an
email from a non-suspect new contact, with the exception of
automated emails such as email alerts, newsletters, advertisements
or any email that has been sent by an automated process; and/or
[0026] When the end user sends an email to a new contact.
[0027] Managing List of Blacklisted Contacts
[0028] According to one embodiment, a list of blacklisted email
contacts called BLACKLIST may also be established and managed. All
email addresses in this list are stored as lowercase. According to
one embodiment, if an email is sent by a sender whose email address
belongs to BLACKLIST, then that email will be dropped and will not
be delivered to the protected user.
[0029] Detecting a Potentially Suspect or Illegitimate Email
Address
[0030] When a protected user receives an email, a check may be
carried out to determine whether the sender's email address is
known. The KNOWN_CONTACTS list may be consulted for this purpose.
If the email address is not known (e.g., is not present in the
KNOWN_CONTACTS list), a determination may be carried out, according
to one embodiment, to determine whether the email address looks
like or is otherwise similar to a known address. An email address
is made up of a local part, the @ symbol and a domain part: [0031]
The local part is the left side of the email address, before the @
symbol. For example, john.smith is the local part of
john.smith@gmail.com. [0032] The domain is the right side of the
email address, after the @ symbol. For example, gmail.com is the
domain of john.smith@gmail.com.
[0033] According to one embodiment, an email may be considered to
be suspect or potentially illegitimate if both of the following
conditions are met: [0034] The email address is not in
KNOWN_CONTACTS, and [0035] The local part of the email address is
equal or close to the local part of an email address of
KNOWN_CONTACTS.
[0036] According to one embodiment, a detection process may be
carried out to determine whether the local part of the received
email address has been spoofed, to appear to resemble the local
part of an email address in the KNOWN_CONTACTS list. According to
one embodiment, such a detection process may utilize a string
metric to compare the local part of an email address in the
KNOWN_CONTACTS with the local part of the received email address. A
string metric (also known as a string similarity metric or string
distance function) is a metric that measures distance ("inverse
similarity") between two text strings for approximate string
matching or comparison and in fuzzy string searching. A string
metric may provide a number that is an indication of the distance
or similarity between two (e.g., alpha or alphanumeric)
strings.
[0037] One embodiment utilizes the Levenshtein Distance (also known
as Edit Distance). The Levenshtein Distance operates between two
input strings, and returns a number equivalent to the number of
substitutions and deletions needed in order to transform one input
string (e.g., the local part of the received email address) into
another (e.g., the local part of an email address in the
KNOWN_CONTACTS list). One embodiment, therefore, computes a string
metric such as the Levenshtein distance to detect if there has been
a likely spoofing of the local part of the received email address.
The Levenshtein distance between two sequences of characters is the
minimum number of single-character edits (i.e. insertions,
deletions or substitutions) required to change one sequence of
characters into the other. Other string metrics that may be used in
this context include, for example, the Damerau-Levenshtein
distance. Others may be used to good benefit as well.
[0038] FIG. 2 is a table showing a legitimate email address, a
spoofed email addresses and a calculated string metric (e.g., a
Levenshtein distance) between the two, according to one embodiment.
In the first row of the table of FIG. 2, the Levenshtein Distance
between the legitimate email address and the address in the Spoofed
email address column is zero, meaning that they are the same and
that no insertions, deletions or substitutions have been made to
the local part. In the second row, the spoofed email addresses'
domain is yahoo.com, whereas the legitimate address' domain is
gmail.com. The spoofed email address, therefore, would not be
present in the KNOWN_CONTACTS, even though the Levenshtein Distance
between the local part of the legitimate email and the local part
of the spoofed email is zero, meaning that they are identical. As
both conditions are met (the email address is not in KNOWN_CONTACTS
and the local part of the email address is equal or close to the
local part of an email address of KNOWN_CONTACTS), the received
john.smith@yahoo.com email would be considered to be suspect or at
least likely illegitimate. The third row of the table in FIG. 2
shows that the Levenshtein Distance between the legitimate email
address and the spoofed email address is 1. In this case, the
difference between the two local parts of the legitimate and
spoofed email addresses is a single substitution of an underscore
for a period. Similarly, the fourth row of the table in FIG. 2
shows that the Levenshtein Distance between the legitimate email
address and the spoofed email address is 1. In this case, the
difference between the two local parts of the legitimate and
spoofed email addresses is a single deletion of period in the local
part of the received email address. The fifth row of the table in
FIG. 2 shows that the Levenshtein Distance between the legitimate
email address and the spoofed email address is 1 as well. In this
case, however, the difference between the two local parts of the
legitimate and spoofed email addresses is a single insertion of an
extra letter "t" in the local part. Lastly, the sixth row of the
table in FIG. 2 shows that the Levenshtein Distance between the
legitimate email address and the spoofed email address is 2.
Indeed, the difference between the two local parts of the
legitimate and spoofed email addresses is a single insertion and a
single deletion, as the period has been deleted and an "1" has been
substitute for the "t" in the local part.
[0039] According to one embodiment, an email address is considered
as suspect if the string metric (the Levenshtein Distance in one
implementation) d between the local part of the email address and
the local part of an email address of KNOWN_CONTACTS is such
that
d.ltoreq.STRING_METRIC_DISTANCE_THRESHOLD
[0040] One implementation may include the following
functionality:
TABLE-US-00001 input : .cndot. address : address to test. lowercase
string. .cndot. known_contacts : list of known contacts. Each
contact is a lowercase string. output : .cndot. true if suspect,
false otherwise # these parameters can be configured according to
the operational conditions and security policy
levenshtein_distance_threshold = 2 localpart_min_length = 6 # if
the localpart is too short, it is not relevant if
address.localpart.length < localpart_min_length : return false #
if the address is already known, it is not suspect if address in
known_contacts : return false # otherwise we check each contact of
known contacts for each known_contact in known_contacts: d =
levenshtein_distance(address.localbart, known_contact.localpart) if
d >=0 and d <= localpart_levenshtein_distance_threshold :
return true # email address is not suspect return false
[0041] Above, the minimum length for the local part of the email
address has been set at 6 characters and the
STRING_METRIC_DISTANCE_THRESHOLD has been set a 2. Of course, other
values may be substituted for these values. Indeed, the parameters
STRING_METRIC DISTANCE_THRESHOLD and localpart_min_length may be
readily configured according to operational conditions and
according to the security policies of the deploying
organization.
[0042] For example, if the STRING_METRIC_DISTANCE_THRESHOLD is
increased, a greater number of spoofing attempts may be detected,
but a greater number of false positives (email addresses that are
legitimate but are flagged as potentially illegitimate) may be
generated. A greater number of false positives may erode the user
experience and degrade the confidence of the protected user in the
system and may lead the user to disregard flagged emails.
[0043] Flagging an Email as Potentially Illegitimate/Generating
Warning Cue
[0044] If the email address is suspect, a visual (for example) cue
(such as a message) may be generated to warn the protected user.
According to one embodiment, the protected user may then be called
upon to make a decision to: [0045] confirm that the email address
is suspect--the email address is then added to BLACKLIST and the
email is dropped; or [0046] deny that the email address is
suspect--the email address is then added to KNOWN_CONTACTS and the
email is delivered to the protected user.
IMPLEMENTATION EXAMPLE
[0047] One implementation may include the following
functionality:
TABLE-US-00002 function : process_email input : .cndot. email :
email received. .cndot. known_contacts : list of known contacts.
Each contact is a lowercase string. .cndot. blacklist : list of
blacklisted contacts. Each contact is a lowercase string. output :
.cndot. true if email has to be dropped, false otherwise # extract
address from From header [1] address = email.from_header.address
address = lowercase (address) # if address is blacklisted, drop
email if address in blacklist : return true # if address is
suspicious, warn user if is_address_suspicious(address,
known_contacts) : # decision is confirmed or denied decision =
warn_end_user(address) if decision is confirmed :
blacklist.append(address) return true else if decision is denied :
known_contacts.append(address) return false # otherwise add address
to known_contacts else : known_contacts.append(address) return
false
[0048] FIG. 3 is a flow chart of a method according to one
embodiment. As shown, block B31 calls for receiving an electronic
message (an email, for example) from a purported known sender over
a computer network. In block B32, a database configured to store a
plurality of known senders of electronic messages (including, for
example, the KNOWN_CONTACTS list discussed above) may be accessed
(either locally or over a LAN or WAN) and it may be determined
whether the purported known sender of the electronic message
matches one of the plurality of known senders of electronic
messages in the database of known senders. As shown at B33, the
degree of similarity of the purported known sender of the
electronic message to one or more one of the plurality of known
senders of electronic messages stored in the database may be
quantified. At B34, it may be determined whether the purported
known sender matches one of the plurality of known senders in the
database of known senders. If, so (Yes branch of B34), the
electronic message originates from a legitimate sender, as shown at
B35, and the message may be safely delivered to its intended
recipient. If the purported known sender does not match one of the
plurality of known senders in the database of known senders (No
branch of B34), it may be determined, as shown at B35, whether the
quantified degree of similarity of the purported known sender of
the electronic message to one of the plurality of known senders of
electronic messages is greater than a threshold value (such as, for
example, the value of the STRING METRIC DISTANCE THRESHOLD
variable, as discussed above). If no, the electronic message may be
legitimate as suggested at B37 or no information may be determined
(at least, the electronic message may be determined to be an
unlikely candidate for a spear phishing attack).
[0049] As shown at B38, if the purported known sender does not
match one of the plurality of known senders in the database of
known senders and the quantified degree of similarity of the
purported known sender of the electronic message to one of the
plurality of known senders of electronic messages is indeed greater
than the threshold value, the received electronic message may be
flagged as being suspect. Thereafter, a visual and/or other
perceptible cue, warning message, dialog box and the like may be
generated when the received electronic message has been flagged as
being suspect, to alert the recipient thereof that the flagged
electronic message is likely illegitimate.
[0050] According to one embodiment, the electronic message may be
or may comprises an email. In Block B33, the quantifying may
comprise calculating a string metric of the difference between the
purported sender and one of the plurality of known senders in the
database of known senders. In one embodiment, the string metric may
comprise a Levenshtein distance between the purported sender and
one of the plurality of known senders in the database of known
senders.
[0051] After block B39, a prompt may be generated, to solicit a
decision confirming the flagged electronic message as being suspect
or a decision denying that the flagged electronic message is
suspect. Thereafter, the electronic message flagged as suspect may
be dropped when the prompted decision is to confirm that the
flagged electronic message is suspect and the flagged electronic
message may be delivered to its intended recipient when the
prompted decision is to deny that the flagged electronic message is
suspect.
[0052] FIG. 4 is a block diagram of a system configured for
phishing detection, according to one embodiment. As shown therein,
a spear phishing email server or workstation (as spear phishing
attacks tend to be somewhat more artisanal than the comparatively
less sophisticated phishing attacks) 402 (not part of the present
spear phishing detection system, per se) may be coupled to a
network (including, for example, a LAN or a WAN including the
Internet), and to a client computing device 412's email server 408.
The email server 408 may be configured to receive the email on
behalf of the client computing device 412 and provide access
thereto. A database 406 of known and trusted senders may also be
coupled to the network 404. A Blacklist database 414 may also be
coupled to the network 404. A phishing detection engine 410 may be
coupled to or incorporated within, the email server 408.
Alternatively, some or all of the functionality of the spear
phishing detection engine 410 may be coupled to or incorporated
within the client computing device 412. Alternatively still, the
functionality of the spear phishing detection engine 410 may be
distributed across both client computing device 412 and the email
server 408. According to one embodiment, the spear phishing
detection engine may be configured to carry out the functionality
described herein above and, in particular, with reference to FIG.
3. The databases 406, 414 may be merged into one database and/or
may be co-located with the email server 408 and/or the spear
phishing detection engine 410.
[0053] Any reference to an engine in the present specification
refers, generally, to a program (or group of programs) that perform
a particular function or series of functions that may be related to
functions executed by other programs (e.g., the engine may perform
a particular function in response to another program or may cause
another program to execute its own function). Engines may be
implemented in software or hardware as in the context of an
appropriate hardware device such as an algorithm embedded in a
processor or application-specific integrated circuit.
[0054] FIG. 5 illustrates a block diagram of a computing device
such as client computing device 412, email server 408 spear
phishing detection engine 410 upon and with which embodiments may
be implemented. Computing device 412, 408, 410 may include a bus
501 or other communication mechanism for communicating information,
and one or more processors 502 coupled with bus 801 for processing
information. Computing device 412, 408, 410 may further comprise a
random access memory (RAM) or other dynamic storage device 504
(referred to as main memory), coupled to bus 501 for storing
information and instructions to be executed by processor(s) 502.
Main memory (tangible and non-transitory) 504 also may be used for
storing temporary variables or other intermediate information
during execution of instructions by processor 502. Computing device
412, 408, 410 may also may include a read only memory (ROM) and/or
other static storage device 506 coupled to bus 501 for storing
static information and instructions for processor(s) 502. A data
storage device 507, such as a magnetic disk and/or solid state data
storage device may be coupled to bus 501 for storing information
and instructions--such as would be required to carry out the
functionality shown and disclosed relative to FIG. 3. The computing
device 412, 408, 410 may also be coupled via the bus 501 to a
display device 521 for displaying information to a computer user.
An alphanumeric input device 522, including alphanumeric and other
keys, may be coupled to bus 501 for communicating information and
command selections to processor(s) 502. Another type of user input
device is cursor control 523, such as a mouse, a trackball, or
cursor direction keys for communicating direction information and
command selections to processor(s) 502 and for controlling cursor
movement on display 521. The computing device 412, 408, 410 may be
coupled, via a communication device (e.g., modem, network interface
card or NIC) to a network 404.
[0055] Embodiments of the present invention are related to the use
of computing device 412, 408, 410 to detect and compute a
probability that received email may be or may include a spear
phishing attack. According to one embodiment, the methods and
systems described herein may be provided by one or more computing
devices 412, 408, 410 in response to processor(s) 502 executing
sequences of instructions contained in memory 504. Such
instructions may be read into memory 504 from another
computer-readable medium, such as data storage device 507.
Execution of the sequences of instructions contained in memory 504
causes processor(s) 502 to perform the steps and have the
functionality described herein. In alternative embodiments,
hard-wired circuitry may be used in place of or in combination with
software instructions to implement the described embodiments. Thus,
embodiments are not limited to any specific combination of hardware
circuitry and software. Indeed, it should be understood by those
skilled in the art that any suitable computer system may implement
the functionality described herein. The computing devices may
include one or a plurality of microprocessors working to perform
the desired functions. In one embodiment, the instructions executed
by the microprocessor or microprocessors are operable to cause the
microprocessor(s) to perform the steps described herein. The
instructions may be stored in any computer-readable medium. In one
embodiment, they may be stored on a non-volatile semiconductor
memory external to the microprocessor, or integrated with the
microprocessor. In another embodiment, the instructions may be
stored on a disk and read into a volatile semiconductor memory
before execution by the microprocessor.
[0056] While certain example embodiments have been described, these
embodiments have been presented by way of example only, and are not
intended to limit the scope of the embodiments disclosed herein.
Thus, nothing in the foregoing description is intended to imply
that any particular feature, characteristic, step, module, or block
is necessary or indispensable. Indeed, the novel methods and
systems described herein may be embodied in a variety of other
forms; furthermore, various omissions, substitutions and changes in
the form of the methods and systems described herein may be made
without departing from the spirit of the embodiments disclosed
herein.
* * * * *