The internet is full of fraud and theft and cybercriminals are operating in the open with impunity, misrepresenting brands and advocating deceit overtly. Bolster found these criminals are using mainstream ISPs, hosting companies and free internet services – the same that are used by legitimate businesses every day. Phishing and online fraud scams accelerate In Q2, there was an alarming, rapid increase of new phishing and fraudulent sites being created, detecting 1.7 million phishing and … More
Threat actors are increasingly using Google services such as Forms, Firebase and Sites to get around email defences that look for suspicious code and URLs, security vendor Armorblox has warned.
In a blog released this morning, the company said infosec pros need to tailor their strategies to prepare for these deceptions, especially if their organization uses free Gmail or GSuite.
Here are several examples of attackers’ tactics Armorblox has seen:
- An email claims to come from a company’s IT team and asks readers to review a secure message their colleagues had shared over Microsoft Teams. Clicking the link takes victims to a page resembling Microsoft Teams, which then when to a credential phishing site resembling the Office 365 login portal.
- The Office 365 login portal was hosted on Google Sites, a wiki and web page creation tool. Victims may be fooled by the legitimacy of the page’s domain, which starts “sites.google.com.”
- An email impersonating an organization’s payroll team goes to named employees with payslip details, asking them to click on a link and check if their personal information for the payslip is accurate. As an extra pressure tactic, the message asks victims to check before 5 p.m.
- The link in the email leads to a page hosted on Google Docs. Since Google Docs is commonly used, some people might not be surprised to see a Google Docs link in an email from a colleague.
- An email pretending to be from an organization’s security team with an email tells victims they haven’t received some ‘vital’ emails because of a storage quota issue. The message includes a link for readers to verify their information and resume email delivery.
The email link leads to a fake login page hosted on Firebase, Google’s mobile platform that enables users to create apps, host files and images, and serve user-generated content. The parent URL of the fake page – https://firebasestorage.googleapis.com – won’t be blocked by any security filters. The login screen for capturing credentials has the email address of the victim pre-entered into the first field.
Some of these tactics won’t fool a sharp-eyed — and well-trained — person if certain defences are in place. For example, if the corporate email is set up to brand messages as coming from an external (outside the company) source, then staff should realize a message purportedly coming from a colleague or another company department must be malicious.
Still, Armorblox recommends infosec staff, if they haven’t already done so to implement multifactor authentication for email accounts and have staff use an approved password manager, making sure staff don’t use common and insecure passwords; train staff to be careful with emails related to money and data and make sure all existing email security capabilities are enabled. Some security vendors may have products that can spot Google service abuse.
The post Hackers are using Google services to bypass email defence, researchers warn first appeared on IT World Canada.
Digital attackers launched a malicious email campaign that used fear of election interference in order to spread the QBot trojan. On November 4, Malwarebytes came across an attack email. This message arrived as a thread reply in an attempt to boost its legitimacy. The body of the email did not include the recipient’s name or […]… Read More
The post Email Attacks Using Fear of Election Interference to Spread QBot appeared first on The State of Security.
Phishing Email Examples: How to Recognize a Phishing Email
Keeping your identity safe on the internet can be challenging. Phishing is a scam that tricks you into voluntarily providing important personal information. Protect yourself from phishing by reviewing some examples of phishing emails and learning more about this common online scam.
What is phishing?
Phishing is a type of cybercrime that steals your sensitive information. To trick you into willingly providing information like your website logins and credit card numbers, phishing scammers disguise themselves as major corporations or other trustworthy entities. Phishing scammers will usually contact you via text or email.
What is a phishing email?
A phishing email is a fraudulent email message that is made to look like it was sent by a legitimate company. These emails contain messages that ask you to provide sensitive personal information in various ways. If you don’t look carefully at the emails you receive, you might not be able to tell the difference between a normal email and a phishing email. Scammers work hard to make phishing emails resemble emails sent by trusted companies as closely as possible, which is why you need to be cautious when you open emails and click the links they contain.
How do you spot a phishing email?
Phishing scammers often undo their own plans by making simple mistakes that are easy to spot once you know how to recognize them. Check for the following signs of phishing every time you open an email:
It’s poorly written
Phishing emails often contain grammatical errors, spelling mistakes, and other telltale signs that they weren’t written by marketing departments at major corporations. Even the biggest companies sometimes make small errors in their emails, but if you see multiple, glaring grammatical errors in an email that asks for your personal information, you might have become the target of a phishing scammer.
The logo doesn’t look right
To enhance the credibility of their emails, phishing scammers often steal the logos of prominent corporations or websites. In many cases, however, they don’t steal corporate logos correctly. The logo in a phishing email might have the wrong aspect ratio, or it might be low-resolution. If you have to squint to make out the logo in an email message, chances are that it’s a phishing email.
The URL doesn’t match
Phishing emails always center around links that you’re supposed to click. There are a few ways to check whether a link you’ve been emailed is legitimate. With some email clients, just hovering over the link will be enough to display its URL. Alternatively, you can right-click the link, copy it, and paste the URL into a word processor. On mobile devices, you can check the URL of a link by pressing and holding it with your finger. If the URL you discover doesn’t match up with the entity that supposedly sent you the email, you might have received a phishing email.
Types of phishing emails
Phishing emails come in all shapes and sizes, but there are a few types of phishing emails that are more common than others. Let’s review some examples of the most frequently sent phishing emails:
Account suspended scam
Some phishing emails appear to notify you that your bank account has been temporarily suspended due to unusual activity. If you receive an account suspension email from a bank that you haven’t opened an account with, delete it immediately, and don’t look back. Suspended account phishing emails from banks you do business with, however, are harder to spot. Use the methods we listed above to check the veracity of the email, and if all else fails, contact your bank directly instead of opening any links within the email you received.
Two-factor authentication scam
Two-factor authentication (2FA) has become common, so you’re probably used to receiving emails that ask you to confirm your login information with six-digit numerical codes. Phishing scammers also know how common 2FA has become, and this service that’s supposed to protect your identity might be used for nefarious purposes. If you receive an email asking you to log into an account to confirm your identity, use the criteria we listed above to verify the authenticity of the message. Be especially wary if you’re asked to provide 2FA for an account you haven’t accessed for a while.
Tax refund scam
Everyone likes getting money from the government. That’s what phishing scammers are counting on when they send you phony IRS refund emails. You should always be careful when an email informs you that you’ve received a windfall of cash, and be especially dubious of emails that were supposedly sent by the IRS since this government agency only contacts taxpayers via snail mail. Tax refund phishing scams can do serious harm since they usually ask for your social security number as well as your bank account information.
Phishing at work
You need to be wary of phishing when you’re using your work email as well. One popular phishing scam involves emails that are designed to look like they were sent by someone in the C-suite of your company. They ask workers to wire funds to supposed clients, but this cash actually goes to scammers. Use the tips we listed above to spot these phony emails.
What happens if you click a link in a phishing email?
Never click links in suspicious emails. If you do click a link in an email you suspect was sent by a phishing scammer, however, you will be taken to a web page with a form where you can enter sensitive data such as your social security number, credit card information, or login credentials. Do not enter any data on this page.
What do you do if you suspect you’ve been phished?
If you accidentally enter data in a webpage linked to a suspicious email, disconnect your device from the internet. Next, perform a full malware scan on your device. Once the scan is complete, backup all of your files, and change your passwords. Even if you only provided a phishing scammer with the data from one account, you may have also opened the door to other personal data, so it’s important to change all the passwords you use online in the wake of a suspected phishing attack.
How to recognize a phishing email: simple tips
Let’s wrap things up with some summarized tips on how to avoid phishing emails:
- When in doubt, directly contact the organization that supposedly emailed you instead of opening links included in suspicious emails.
- Examine suspicious emails carefully to check for telltale signs of phishing such as poor grammar, grainy logos, or bogus links.
- If you accidentally click a phishing link, don’t enter any data, and close the page.
- If you think you’ve been phished, run a virus scan, backup your files, and change all your passwords.
Phishing emails only work on the unwary. Now that you know how to spot phishing emails and what to do if you suspect you’ve been phished, you won’t fall for this type of scam. Just remember to always be careful with your personal information when you use the internet, and err on the side of caution whenever anybody asks you to divulge sensitive details about your identity, your finances, or your login information.
The post Phishing Email Examples: How to Recognize a Phishing Email appeared first on McAfee Blogs.
With Business Email Compromises (BECs) showing no signs of slowing down, it is becoming increasingly important for security analysts to understand Office 365 (O365) breaches and how to properly investigate them. This blog post is for those who have yet to dip their toes into the waters of an O365 BEC, providing a crash course on Microsoft’s cloud productivity suite and its assortment of logs and data sources useful to investigators. We’ll also go over common attacker tactics we’ve observed while responding to BECs and provide insight into how Mandiant Managed Defense analysts approach these investigations at our customers using PowerShell and the FireEye Helix platform.
Office 365 is Microsoft’s cloud-based subscription service for the Microsoft Office suite. It is built from dozens of applications tightly embedded into the lives of today’s workforce, including:
- Exchange Online, for emails
- SharePoint, for intranet portals and document sharing
- Teams and Skype for Business, for instant messaging
- OneDrive, for file sharing
- Microsoft Stream, for recorded meetings and presentations
As more and more organizations decide to adopt Microsoft’s cloud-based offering to meet their needs, unauthorized access to these O365 environments, or tenants in Microsoft’s parlance, has become increasingly lucrative to motivated attackers. The current high adoption rate of O365 means that attackers are getting plenty of hands on experience with using and abusing the platform. While many tactics have remained largely unchanged in the years since we’ve first observed them, we’ve also witnessed the evolution of techniques that are effective against even security-conscious users.
In general, the O365 compromises we’ve responded to have fallen into two categories:
- Business Email Compromises (BECs)
- APT or state-sponsored intrusions
Based on our experience, BECs are a common threat to any organization's O365 tenant. The term “BEC” typically refers to a type of fraud committed by financially motivated attackers. BEC actors heavily rely on social engineering to carry out their schemes, ultimately defrauding organizations and even personnel.
One common BEC scheme involves compromising a C-suite executive’s account via phishing. Once the victim unwittingly enters their credentials into a web form masquerading as the legitimate Office 365 login portal, attackers log in and instruct others in the organization to conduct a wire transfer, perhaps under the guise of an upcoming acquisition that has yet to be publicly announced. However, we’ve also observed more effective schemes where attackers compromise those in financial positions and patiently wait until an email correspondence has begun about a due payment. Attackers seize this opportunity by sending a doctored invoice (sometimes based on a legitimate invoice that had been stolen earlier) on behalf of the compromised user to another victim responsible for making payments. These emails are typically hidden from the compromised user due to attacker-created Outlook mailbox rules. Often times, by the time the scheme is inevitably discovered and understood days or weeks later, the money is unrecoverable—highlighting the importance of contacting law enforcement immediately if you’ve fallen victim to a fraud.
The personal finances of staff aren’t off limits to attackers either. We’ve observed several cases of W-2 scams, in which attackers send a request to HR for W-2 information from the victim’s account. Once obtained, this personally identifiable information is later used to conduct tax fraud.
Conversely, APT intrusions are typically more sophisticated and are conducted by state-sponsored threat actors. Rather than for financial gain, APT actors are usually tasked to compromise O365 tenants for purposes of espionage, data theft, or destruction. Given the wealth of sensitive information housed in any given organization’s O365 tenant, APT actors may not even need to touch a single endpoint to complete their mission, sidestepping the many security controls organizations have implemented and invested in.
O365 Logs and Data Sources
In this section, we’ll touch on the multitude of logs and portals containing forensic data relevant to an O365 investigation.
Before we can begin investigating an O365 case, we’ll work with our clients to get an “Investigator” account provisioned with the roles required to obtain the forensic data we need. For the purposes of this blog post, we’ll quickly list the roles needed for an Investigator account, but during an active Managed Defense investigation, a designated Managed Defense consultant will provide further guidance on account provisioning.
At a minimum, the Investigator account should have the following roles:
Exchange Admin Roles
- View-only audit logs
- View-only configuration
- View-only recipients
- Mailbox Search
- Message Tracking
- eDiscovery Manager role
Azure Active Directory Roles
- Global Reader
Unified Audit Log (UAL)
The Unified Audit Log records activity from various applications within the Office 365 suite, and can be considered O365’s main log source. Entries in the UAL are stored in JSON format. We recommend using the PowerShell cmdlet Search-UnifiedAuditLog to query the UAL as it allows for greater flexibility, though it can also be acquired from the Office 365 Security & Compliance Center located at protection.office.com. In order to leverage this log source (and the Admin Audit Log), ensure that the Audit Log Search feature is enabled.
The UAL has a few nuances that are important to consider. While it provides a good high-level summary of activity across various O365 applications, it won’t log comprehensive mailbox activity (for that, acquire the Mailbox Audit Log). Furthermore, the UAL has a few limitations, namely:
- Results to a single query are limited to 5000 results
- Only 90 days of activity are retained
- Events may take up to 24 hours before they are searchable
Mailbox Audit Log (MAL)
The Mailbox Audit Log, part of Exchange Online, will capture additional actions performed against objects within a mailbox. As such, it’s a good idea acquire and analyze the MAL for each affected user account with the PowerShell cmdlet Search-MailboxAuditLog. Note that entries in the MAL will be retained for 90 days (by default) and timestamps will be based on the user’s local time zone. The MAL’s retention time can always be increased with the PowerShell cmdlet Set-Mailbox along with the AuditLogAgeLimit parameter.
At the time of writing this post, Microsoft has recently released information about enhanced auditing functionality that gives investigators insight into which emails were accessed by attackers. This level of logging for regular user accounts is only available for organizations with an Office 365 E5 subscription. Once Advanced Auditing is enabled, mail access activity will be logged under the MailItemsAccessed operation in both the UAL and MAL.
Administrator Audit Log
If the Audit Log Search feature is enabled, this supplemental data source logs all PowerShell administrative cmdlets (including command-line arguments) executed by administrators. If you suspect that an administrator account was compromised, don’t overlook this log! The PowerShell cmdlet Search-AdminAuditLog is used to query these logs, but note that the Audit Log Search feature must be enabled and the same 90 day retention limit will be in place.
Azure AD Logs
Azure AD logs can be accessed from the Azure portal (portal.azure.com) under the Azure Active Directory service. Azure AD Sign-in logs contain detailed information about how authentications occur and O365 application usage. Azure AD audit logs are also a valuable source of information, containing records of password resets, account creations, role modifications, OAuth grants, and more that could be indicative of suspicious activity. Note that Azure AD logs are only available for 30 days.
Cloud App Security Portal
For cases where OAuth abuse has been observed, information about cloud applications can be found in Microsoft’s Cloud App Security portal (portal.cloudappsecurity.com). Access to this portal requires an E5 license or a standalone Cloud App license. For more background on OAuth abuse, be sure to check out our blog post: Shining a Light on OAuth Abuse with PwnAuth.
Message traces record the emails sent and received by a user. During an investigation, run reports on any email addresses of interest. The message trace report will contain detailed mail flow information as well as subject lines, original client IP addresses, and message sizes. Message traces are useful for identifying emails sent by attackers from compromised accounts, and can also aid in identifying initial phishing emails if phishing was used for initial access. To obtain the actual emails, use the Content Search tool.
Only the past 10 days of activity is available with the Get-MessageTrace PowerShell cmdlet. Historical searches for older messages can be run with the Get-HistoricalSearch cmdlet (up to 90 days by default), but historical searches typically take hours for the report to be available. Historical reports can also be generated within the Security and Compliance Center.
eDiscovery Content Searches
The Content Search tool allows investigators to query for emails, documents, and instant message conversations stored in an Office 365 tenant. We frequently run Content Search queries to find and acquire copies of emails sent by attackers. Content searches are limited to what has been indexed by Microsoft, so recent activity may not immediately appear. Additionally, only the most recent 1000 items will be shown in the preview pane.
Anatomy of an O365 BEC
As mentioned earlier, BECs are one of the more prevalent threats to O365 tenants seen by Managed Defense today. Sometimes, Mandiant analysts respond to several BEC cases at our customers within the same week. With this frontline experience, we’ve compiled a list of commonly observed tactics and techniques to advise our readers about the types of activities one should anticipate. Please note that this is by no means a comprehensive list of O365 attacks, rather a focus on the usual routes we’ve seen BEC actors take to accomplish their objective.
Phase 1: Initial Compromise
- Phishing: Emails with links to credential harvesting forms sent to victims, sometimes from the account of a compromised business partner.
- Brute force: A large dictionary of passwords attempted against an account of interest.
- Password spray: A dictionary of commonly used passwords attempted against a list of known user accounts.
- Access to credential dump: Valid credentials used from a previous compromise of the user.
- MFA bypasses: Use of mail clients leveraging legacy authentication protocols (e.g. IMAP/POP), which bypass MFA policies. Attackers may also spam push notifications to the victim by repeatedly attempting to log in, eventually leading to the victim mistakenly accepting the prompt.
Phase 2: Establish Foothold
- More phishing: Additional phishing lures sent to internal/external contacts from Outlook’s global address list.
- More credible lures: New phishing lures uploaded to the compromised user's OneDrive or SharePoint account and shared with the victim’s coworkers.
- SMTP forwarding: SMTP forwarding enabled in the victim’s mailbox to forward all email to an external address.
- Forwarding mailbox rules: Mailbox rules created to forward all or certain mail to an external address.
- Mail client usage: Outlook or third-party mail clients used by attackers. Mail will continue to sync for a short while after a password reset occurs.
Phase 3: Evasion
- Evasive mailbox rules: Mailbox rules created to delete mail or move some or all incoming mail to uncommonly used folders in Outlook, such as “RSS Subscriptions”.
- Manual evasion: Manual deletion of incoming and sent mail. Attackers may forego mailbox rules entirely.
- Mail forwarding: Attackers accessing emails without logging in if a mechanism to forward mail to an external address was set up earlier.
- Mail client usage: Outlook or third-party mail clients used by attackers. Mail can be synced locally to the attacker’s machine and accessed later.
- VPN usage: VPN servers, sometimes with similar geolocations to their victims, used in an attempt to avoid detection and evade conditional access policies.
Phase 4: Internal Reconnaissance
- Outlook searching: The victim’s mailbox queried by attackers for emails of interest. While not recorded in audit logs, it may be available to export if it was not deleted by attackers.
- O365 searching: Searches conducted within SharePoint and other O365 applications for content of interest. While not recorded in audit logs, SharePoint and OneDrive file interactions are recorded in the UAL.
- Mail client usage: Outlook or third-party mail clients used by attackers. Mail can be synced locally to the attacker’s machine and accessed later.
Phase 5: Complete Mission
- Direct deposit update: A request sent to the HR department to update the victim’s direct deposit information, redirecting payment to the BEC actor.
- W-2 scam: A request sent to the HR department for W-2 forms, used to harvest PII for tax fraud.
- Wire transfer: A wire transfer requested for an unpaid invoice, upcoming M&A, charities, etc.
- Third-party account abuse: Abuse of the compromised user’s privileged access to third-party accounts and services, such as access to a corporate rewards site.
How Managed Defense Responds to O365 BECs
In this section, we’re going to walk through how Managed Defense investigates a typical O365 BEC case.
Many of the steps in our investigation rely on querying for logs with PowerShell. To do this, first establish a remote PowerShell session to Exchange Online. The following Microsoft documentation provides guidance on two methods to do this:
- Connect to Exchange Online PowerShell with Basic authentication
- Use the Exchange Online PowerShell with modern authentication using V2 module
We start our investigations off by running broad queries against the Unified Audit Log (UAL) for suspicious activity. We’ll review OAuth activity too, which is especially important if something more nefarious than a financially motivated BEC is suspected. Any FireEye gear available to us—such as FireEye Helix and Email Security—will be leveraged to augment the data available to us from Office 365.
The following are a few initial scoping queries we’d typically run at the beginning of a Managed Defense engagement.
Scoping Recent Mailbox Rule Activity
Even in large tenants, pulling back all recent mailbox rule activity doesn’t typically produce an unmanageable number of results, and attacker-created rules tend to stand out from the rest of the noise.
Querying UAL for all mailbox rule activity in Helix:
|class=ms_office365 action:[New-InboxRule, Set-InboxRule, Enable-InboxRule] | table [createdtime, action, username, srcipv4, srcregion, parameters, rawmsg]|
Query UAL for new mail rule activity in PowerShell:
|Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -ResultSize 5000 -Operations "New-InboxRule","Set-InboxRule","Enable-InboxRule" | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
Scoping SMTP Forwarding Activity
SMTP forwarding is sometimes overlooked because it appears under a UAL operation separate from mailbox rules. This query looks for the Set-Mailbox operation containing a parameter to forward mail over SMTP, indicative of automatic forwarding being enabled from OWA.
Querying UAL for SMTP forwarding in Helix:
|class=ms_office365 action=Set-Mailbox rawmsg:ForwardingSmtpAddress | table [createdtime, action, username, srcipv4, srcregion, parameters, rawmsg]|
Querying UAL for SMTP forwarding in PowerShell:
|Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -ResultSize 5000 -FreeText "ForwardingSmtpAddress" | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
Analyze Compromised Users Logs
After we’ve finished scoping the tenant, we’ll turn our attention to the individual users believed to be involved in the compromise. We’ll acquire all relevant O365 logs for the identified compromised user(s) - this includes the user's UAL, Mailbox Audit Log (MAL), and Admin audit log (if the user is an administrator). We’ll review these logs for anomalous account activity and assemble a list of attacker IP addresses and User-Agents strings. We’ll use this list to further scope the tenant.
O365 investigations rely heavily on anomaly detection. Many times, the BEC actor may even be active at the same time as the user. In order to accurately differentiate between legitimate user activity and attacker activity within a compromised account, it's recommended to pull back as much data as possible to use as a reference for legitimate activity. Using the Helix query transforms groupby < [srccountry,srcregion], groupby < useragent and groupby < srcipv4 , which highlight the least common geolocations, User Agent strings, and IP addresses, can also assist in identifying anomalies in results.
Querying UAL for a user in Helix:
|class=ms_office365 email@example.com | table [createdtime, action, username, srcipv4, srccountry, srcregion, useragent, rawmsg] | groupby < [srccountry,srcregion]|
Querying UAL for a user in PowerShell:
|Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -UserIds firstname.lastname@example.org | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
Querying MAL for a user in PowerShell:
|Search-MailboxAuditLog -Identity email@example.com -LogonTypes Owner,Delegate,Admin -ShowDetails -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
Querying Admin Audit Log for all events within a certain date in PowerShell:
|Search-AdminAuditLog -StartDate mm/dd/yyyy -EndDate mm/dd/yyyy | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
Query UAL with New Leads
Now that we’ve built a list of suspicious IP addresses (or even entire CIDR ranges) and User-Agent strings, we’ll run new queries against the entire UAL to try to identify other compromised user accounts. We’ll repeat this step and the previous step for each newly identified user account.
One advantage to using FireEye Helix platform over PowerShell is that we can query entire CIDR ranges. This is helpful when we observe attackers coming from a VPN or ISP that dynamically assigns IP addresses within the same address block.
Queries for attacker User-Agent strings usually generate more noise to sift through than IP address searches. In practice, User-Agent queries are only beneficial if the attackers are using an uncommon browser or version of a browser. Due to limitations of the Search-UnifiedAuditLog cmdlet, we’ve had the most success using the FreeText parameter and searching for simple strings.
|class=ms_office365 (srcipv4:[220.127.116.11, 18.104.22.168/24] OR useragent:Opera) | table [createdtime, action, username, srcipv4, srccountry, srcregion, useragent, rawmsg] | groupby username|
Querying the UAL for IPs and user agents in PowerShell:
|Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -IPAddresses 22.214.171.124, 126.96.36.199 | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
|Search-UnifiedAuditLog -StartDate mm/dd/yyyy -EndDate (Get-Date) -ResultSize 5000 -FreeText "Opera" | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
Analyze Message Traces
We’ll use PowerShell to query message traces for the compromised users we’ve identified. If the email was sent within the past 10 days, use the Get-MessageTrace cmdlet, which immediately returns results and allows teams to query IP addresses. For older emails, use the Start-HistoricalSearch cmdlet and download the report later from the Mail Flow section of the Security & Compliance center.
Querying for the last 10 days of mail sent by the victim in PowerShell:
|Get-MessageTrace -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date) -SenderAddress firstname.lastname@example.org | Select-Object Received, SenderAddress, RecipientAddress, Subject, Status, FromIP, Size, MessageID | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8|
Querying for older emails (up to 90 days) in PowerShell:
|Start-HistoricalSearch -ReportTitle "Mandiant O365 investigation" -StartDate mm/dd/yyyy -EndDate mm/dd/yyyy -ReportType MessageTraceDetail -SenderAddress email@example.com|
As Message Trace results are reviewed, attention should be given to IP addresses to determine which emails were sent by attackers. If phishing was the suspected initial compromise vector, it’s a good idea to also query for incoming mail received within a few days prior to the first compromise date and look for suspicious sender addresses and/or subject lines.
Acquire Emails of Interest
With our list of suspicious emails identified from message traces, we’ll use the Content Search tool available in the Office 365 Security and Compliance Center acquire the email body and learn what domains were used in phishing lures (if phishing was present). Content Searches are performed by using a straightforward GUI, and the results can either be previewed in the browser, downloaded individually as EML files, or downloaded in bulk as PST files.
At this point of our investigation, the BEC should be sufficiently scoped within the tenant. To ensure any follow-on activity hasn’t occurred, we’ll take all of the attack indicators and perform our final queries across the UAL.
With that said, there are still edge cases in which attacker activity wouldn’t appear in O365 logs. For example, perhaps an additional user has submitted their credentials to a phishing page, but the attackers haven’t used them to log in yet. To ensure we don’t miss this activity, we’ll perform additional scoping across available network logs, specifically for IP addresses and domains related to the attacker’s phishing infrastructure. We’ll also leverage other FireEye products, such as the Endpoint Security platform, to search for phishing domains present on a host’s web browser history.
Unauthorized access to O365 tenant doesn’t just pose a threat to an organization, but also to its staff and business partners. Organizations without enhanced security controls in O365 are at the greatest risk of experiencing a BEC. However, as multi factor-authentication becomes more and more commonplace, we’ve witnessed an increase of MFA bypass attempts performed by increasingly proficient attackers.
It’s important to remember that social engineering plays a primary role throughout a BEC. Ensure that users are trained on how to identify credential harvesting forms, a common compromise vector. When in the midst of a BEC compromise, teams may want to promptly alert personnel in HR and finance-related roles to exercise extra caution when processing requests related to banking or wire transfers while the investigation is in progress.
The examples covered in this blog post are just a sample of what Managed Defense performs while investigating an Office 365 compromise. To take a proactive approach at preventing BECs, make sure the following best practices are implemented in a O365 tenant. Additionally, FireEye Email Security offers protections against phishing and the Helix platform’s O365 ruleset can alert on anomalous activity as soon as it happens.
Recommended Best Practices
- Ensure mailbox audit logging is enabled on all accounts
- Disable Legacy Authentication protocols
- Enable multi-factor authentication (MFA)
- Enforce strong passwords and a password expiration policy
- Forward O365 audit logs to a centralized logging platform for extended retention
- Enforce an account lockout policy in Azure/on-premise Active Directory
- Restrict mail forwarding to external domains
Special thanks to Doug Bienstock, Glenn Edwards, Josh Madeley, and Tim Martin for their research and assistance on the topic.
FireEye Labs has been tracking a recent spike in malicious email detections that we attribute to a campaign that began in 2013. While malicious email campaigns are nothing new, this one is significant in that we are observing mass-targeting attackers adopting the malware evasion methods pioneered by the stealthier APT attackers. And this is certainly a high-volume business, with anywhere from a few hundred to ten thousand malicious emails sent daily – usually distributing between 50 and 500,000 emails per outbreak.
Through the FireEye Dynamic Threat Intelligence (DTI) cloud, FireEye Labs discovered that each and every major spike in email blasts brought a change in the attributes of their attack. These changes have made it difficult for anti-virus, IPS, firewalls and file-based sandboxes to keep up with the malware and effectively protect endpoints from infection. Worse, if past is prologue, we can expect other malicious, mass-targeting email operators to adopt this approach to bypass traditional defenses.
This blog will cover the trends of the campaign, as well as provide a short technical analysis of the payload.
Figure 1: Attack Architecture
The campaign first appeared in late December of 2013 and has since been seen in fairly cyclical patterns each month. It appears that the threat actors behind this campaign are fairly responsive to published blogs and reports surrounding their malware techniques, tweaking their malware accordingly to continuously try and evade detection with success.
In late 2013, malware labeled as Kuluoz, the specific spam component of the Asprox botnet, was discovered to be the main payload of what would become the first malicious email campaign. Since then, the threat actors have continuously tweaked the malware by changing its hardcoded strings, remote access commands, and encryption keys.
Previously, Asprox malicious email campaigns targeted various industries in multiple countries and included a URL link in the body. The current version of Asprox includes a simple zipped email attachment that contains the malicious payload “exe.” Figure 2 below represents a sample message while Figure 3 is an example of the various court-related email headers used in the campaign.
Figure 2 Email Sample
Figure 3 Email Headers
Some of the recurring campaign that Asporox used includes themes focused around airline tickets, postal services and license keys. In recent months however, the court notice and court request-themed emails appear to be the most successful phishing scheme theme for the campaign.
The following list contains examples of email subject variations, specifically for the court notice theme:
- Urgent court notice
- Notice to Appear in Court
- Notice of appearance in court
- Warrant to appear
- Pretrial notice
- Court hearing notice
- Hearing of your case
- Mandatory court appearance
The campaign appeared to increase in volume during the month of May. Figure 4 shows the increase in activity of Asprox compared to other crimewares towards the end of May specifically. Figure 5 highlights the regular monthly pattern of overall malicious emails. In comparison, Figure 6 is a compilation of all the hits from our analytics.
Figure 4 Worldwide Crimeware Activity
Figure 5 Overall Asprox Botnet tracking
Figure 6 Asprox Botnet Activity Unique Samples
These malicious email campaign spikes revealed that FireEye appliances, with the support of DTI cloud, were able to provide a full picture of the campaign (blue), while only a fraction of the emailed malware samples could be detected by various Anti-Virus vendors (yellow).
Figure 7 FireEye Detection vs. Anti-Virus Detection
By the end of May, we observed a big spike on the unique binaries associated with this malicious activity. Compared to the previous days where malware authors used just 10-40 unique MD5s or less per day, we saw about 6400 unique MD5s sent out on May 29th. That is a 16,000% increase in unique MD5s over the usual malicious email campaign we’d observed. Compared to other recent email campaigns, Asprox uses a volume of unique samples for its campaign.
Figure 8 Asprox Campaign Unique Sample Tracking
Figure 9 Geographical Distribution of the Campaign
Figure 10 Distribution of Industries Affected
Brief Technical Analysis
Figure 11 Attack Architecture
The infiltration phase consists of the victim receiving a phishing email with a zipped attachment containing the malware payload disguised as an Office document. Figure 11 is an example of one of the more recent phishing attempts.
Figure 12 Malware Payload Icon
Once the victim executes the malicious payload, it begins to start an svchost.exe process and then injects its code into the newly created process. Once loaded into memory, the injected code is then unpacked as a DLL. Notice that Asprox uses a hardcoded mutex that can be found in its strings.
- Typical Mutex Generation
- Create svchost.exe process
- Code injection into svchost.exe
Once the dll is running in memory it then creates a copy of itself in the following location:
It’s important to note that the process will first check itself in the startup registry key, so a compromised endpoint will have the following registry populated with the executable:
The malware uses various encryption techniques to communicate with the command and control (C2) nodes. The communication uses an RSA (i.e. PROV_RSA_FULL) encrypted SSL session using the Microsoft Base Cryptographic Provider while the payloads themselves are RC4 encrypted. Each sample uses a default hardcoded public key shown below.
Default Public Key
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
First Communication Packet
Bot ID RC4 Encrypted URL
User-Agent: <host useragent>
Host: <host ip>:443
In comparison to the campaign at the end of 2013, the current campaign uses one of the newer versions of the Asprox family where threat actors added the command “ear.”
if ( wcsicmp(Str1, L"idl") )
if ( wcsicmp(Str1, L"run") )
if ( wcsicmp(Str1, L"rem") )
if ( wcsicmp(Str1, L"ear")
if ( wcsicmp(Str1, L"rdl") )
if ( wcsicmp(Str1, L"red") )
if ( !wcsicmp(Str1, L"upd") )
|idl idl||This commands idles the process to wait for commands This commands idles the process to wait for commands|
|run run||Download from a partner site and execute from a specified path Download from a partner site and execute from a specified path|
|rem rem||Remove itself Remove itself|
|ear ear||Download another executable and create autorun entry Download another executable and create autorun entry|
|rdl rdl||Download, inject into svchost, and run Download, inject into svchost, and run|
|upd upd||Download and update Download and update|
|red red||Modify the registry Modify the registry|
C2 Campaign Characteristics
For the two major malicious email campaign spikes in April and May of 2014, separate sets of C2 nodes were used for each major spike.
|188.8.131.52 184.108.40.206||220.127.116.11 18.104.22.168|
|22.214.171.124 126.96.36.199||188.8.131.52 184.108.40.206|
|220.127.116.11 18.104.22.168||22.214.171.124 126.96.36.199|
|188.8.131.52 184.108.40.206||220.127.116.11 18.104.22.168|
|22.214.171.124 126.96.36.199||188.8.131.52 184.108.40.206|
|220.127.116.11 18.104.22.168||22.214.171.124 126.96.36.199|
|188.8.131.52 184.108.40.206||220.127.116.11 18.104.22.168|
|22.214.171.124 126.96.36.199||188.8.131.52 184.108.40.206|
|220.127.116.11 18.104.22.168||22.214.171.124 126.96.36.199|
|188.8.131.52 184.108.40.206||220.127.116.11 18.104.22.168|
The data reveals that each of the Asprox botnet’s malicious email campaigns changes its method of luring victims and C2 domains, as well as the technical details on monthly intervals. And, with each new improvement, it becomes more difficult for traditional security methods to detect certain types of malware.
Nart Villeneuve, Jessa dela Torre, and David Sancho. Asprox Reborn. Trend Micro. 2013. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-asprox-reborn.pdf