Monthly Archives: July 2020

Cybersecurity Best Practices for SMB IT

It’s time to recalibrate your thinking if you believe your enterprise is safe from hackers because your business is considered small. Yes, system incursions upon the likes of Microsoft, Estee Lauder and T-Mobile get the lion’s share of media attention, however cybercriminals hungrily eye higher-volume smaller targets as well. Making them all the more appetizing is the complacency many small business owners have when it comes to network security.

With that in mind, let’s take a look at some cybersecurity best practices for SMB IT.

  1. Take It Seriously

Sure, this might sound like something that doesn’t need to be said, but a surprising number of data breaches occur because people neglect to treat security as a priority. Employees get lazy about scrutinizing emails and text messages carefully before opening links and attachments. Passwords go unchanged for years because they’re easy to remember. Access codes are shared among “trusted” employees. First and foremost, cybersecurity should be afforded the respect it deserves because ignoring it can shut a company down altogether.

  1. Carry Cyber Insurance

It’s important to operate from the mindset of what will happen when your system is attacked, as opposed to if. This makes carrying a cyber insurance policy with a reputable carrier a good idea. In addition to providing vital financial assistance in the wake of a data breach, cyber insurers scrutinize your security arrangements before agreeing to issue a policy. In other words, they look for ways to infiltrate your network and show you how to plug those gaps before they cover you.

  1. Employ Multi Factor Authentication (MFA)

This one goes somewhat hand in hand with number one above. Prioritizing convenience over security can leave your system open to infiltrators. While requiring multi-factor authentication before permitting access to your network does mean users must take additional steps, it also introduces another hurdle of protection over which interlopers must leap. Compromised, reused and weak passwords are responsible for 81 percent of hacking related breaches. MFA is one of the easiest and most effective measures you can take to ramp up enterprise cybersecurity.

  1. Implement and Enforce a Bring Your Own Device Policy

The Internet of Things has given rise to a plethora of endpoint devices, many of which represent a potential point of entry to your network. This must be addressed head-on. Forbid — and take steps to prevent — the storage of sensitive data on personal devices. Permit access to sensitive information only through an encrypted VPN. Employee owned devices should be granted guest access only over the internet. And, devise and implement an emergency response plan of the steps to take when an employee loses a device. The more endpoints are accessing your network, the more important it is to take cloud and on-premises network security seriously.

  1. ABU — Always Be Updating

Next to weak passwords, old software is another leading cause of data breaches. We know you’ve heard it hundreds of times before, but that should render it all the more important in your mind. Install software updates the moment they become available. This is especially critical for security, web server, and operating system software. Each new version of these contains updated anti-virus and anti-malware coding, typically in response to the latest breach. In other words, hackers find ways in and programmers lock those doors as soon as they become aware of them. Ignoring updates leaves your system vulnerable to people who are aware of those portals.

Always be updating.

These are five of the simplest ways to protect your network. Even better, they can be implemented at minimal cost. Being small is no guarantee criminals will overlook your business. Implementing these cyber security best practices for SMB IT helps prevent your company from being viewed as low hanging fruit, encouraging hackers to look for an easier target.

The post Cybersecurity Best Practices for SMB IT appeared first on Hacker Combat.

Obscured by Clouds: Insights into Office 365 Attacks and How Mandiant Managed Defense Investigates

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

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 Rights

  • 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

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:

Broad Scoping

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 username=user@client.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 user@client.com | Export-CSV \path\to\file.csv –NoTypeInformation -Encoding utf8

Querying MAL for a user in PowerShell:

Search-MailboxAuditLog -Identity user@client.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.

In Helix:

class=ms_office365 (srcipv4:[1.2.3.4, 2.3.4.0/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 1.2.3.4, 2.3.4.5 | 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 victim@client.com | 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 victim@client.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.

Final Scoping

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.

Conclusion

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

Acknowledgements

Special thanks to Doug Bienstock, Glenn Edwards, Josh Madeley, and Tim Martin for their research and assistance on the topic.

‘Ghostwriter’ Influence Campaign: Unknown Actors Leverage Website Compromises and Fabricated Content to Push Narratives Aligned With Russian Security Interests

Mandiant Threat Intelligence has tied together several information operations that we assess with moderate confidence comprise part of a broader influence campaign—ongoing since at least March 2017—aligned with Russian security interests. The operations have primarily targeted audiences in Lithuania, Latvia, and Poland with narratives critical of the North Atlantic Treaty Organization’s (NATO) presence in Eastern Europe, occasionally leveraging other themes such as anti-U.S. and COVID-19-related narratives as part of this broader anti-NATO agenda. We have dubbed this campaign “Ghostwriter.”

Many, though not all of the incidents we suspect to be part of the Ghostwriter campaign, appear to have leveraged website compromises or spoofed email accounts to disseminate fabricated content, including falsified news articles, quotes, correspondence and other documents designed to appear as coming from military officials and political figures in the target countries.

This falsified content has been referenced as source material in articles and op-eds authored by at least 14 inauthentic personas posing as locals, journalists and analysts within those countries. These articles and op-eds, primarily written in English, have been consistently published to a core set of third-party websites that appear to accept user-submitted content, most notably OpEdNews.com, BalticWord.com, and the pro-Russian site TheDuran.com, among others, as well as to suspected Ghostwriter-affiliated blogs.

Some of these incidents and personas have received public attention from researchers, foreign news outlets, or government entities in Lithuania and Poland, but have not been tied to a broader activity set. Others have received little attention and remain relatively obscure. Mandiant Threat Intelligence has independently discovered several Ghostwriter personas and identified additional incidents involving some of those personas previously exposed.

We believe the assets and operations discussed in this report are for the first time being collectively tied together and assessed to comprise part of a larger, concerted and ongoing influence campaign.

Read the report today to learn more.

Keeping Consumer Data Safe

Every day on popular eCommerce sites, millions upon millions of people are entering valuable information. Their names, their credit card information, their addresses, and more all being uploaded in rapid quantities. All this sensitive info, especially in regards to payment profiles, has since become the target for malicious cyber attacks and hacking schemes. For businesses implementing their online payment systems, how can they ensure that consumer data is kept safe?

What does Cyber Attacks Look Like

Hackers typically target valuable data in order to steal money and are usually able to do it before the customers even realize that something is amiss. There are all sorts of ways hackers can access information, like sending malicious code to websites that intercept payments or using bots to guess millions of combinations of letters and numbers to access user accounts. Some hackers won’t even stop at individual users but target a website’s entire back-end database. While these attacks are relentless, there are thankfully several things most businesses do in order to keep sensitive information out of criminal hands.

Ways to Keep Data Secure

There are a lot of methods employed by businesses that keep personal data protected. With these methods, even the most persistent hackers find it impossible to break through and steal data. Data encryption is one leading method. Here data is encoded in such a way that it’s incomprehensible to anyone besides the holder of the key to decrypt it. Encryption uses algorithms to scramble data and obscure it from any prying eyes. Many organizations also make use of SSL certificates to encrypt payment information while it’s in transit.

Frequent updates and use of antivirus or anti-malware software are common practices among businesses. With viruses getting more advanced and hackers finding new methods to work their way into systems, most companies apply frequent updates and patches to all their software offerings and services. These updates not only provide increased stability, new features, and faster operation but offer an increase in security as well. Some businesses even hire ethical hackers to try and break into their own systems so that solutions can be uncovered.

There are also many legal guidelines for businesses to follow that work in tandem with keeping consumer data safe. For example, the Children’s Online Privacy Protection Act prohibits the gathering of data for kids under 13, keeping their sensitive information offline entirely. For other types of data, The California Consumer Privacy Act, and the General Data Protection Regulation (GDPR) set guidelines for the collection and management of personal information. Depending on local laws, there are several regulations just like these that work to keep data in good hands. Some online services like Magento 2 GDPR Extension will even allow online stores to change their processing methods to stay GDPR and CCPA compliant.

While it’s a sad fact online cyber-attacks may never truly go away, we can rest assured that businesses have a wide variety of tools at their disposal to make the internet and their marketplaces safe for all users.

The post Keeping Consumer Data Safe appeared first on Hacker Combat.

How Do Random Number Generators Work?

In a real-world casino, random chance plays a huge part in ensuring that games are fair. If neither the player nor the house can predict which card will be drawn next, or where the ball will stop on a roulette wheel, then the games are unpredictable, and therefore fair. Whilst relying on the laws of physics, or the near-infinite number of combinations that a deck of cards can be arranged into is easy in real life, when it comes to online casinos, things aren’t so simple.

The problem is that making something truly random is really quite difficult. Humans are very bad at creating random combinations, and computer programs need to base any number that they generate on an already existing set of data and human input, so how does the casino industry do it?

Random Number Generators

Random number generators (RNGs) are the subject of many essays and scientific papers, but to put it simply, they work by starting with a number, known as a seed number, and perform a different mathematical problem on that number every time a new random number needs to be generated. Simple, right? Not quite. The seed number can often be over 200,000 digits long, and can change every second, making hacking extremely difficult, if not impossible. The original seed number and the algorithm used to generate the math problem are kept top secret, so whilst there is technically a pattern, without both of those pieces of information, the system is as good as totally random.

The Real World Applications of RNGs

Ok, so now we have a very long string of digits that after having a math problem applied to them, become another number, how does this affect what happens when you play any of the variety of betting games at Paddy Power? Each outcome in each game, whether you’re rolling a virtual dice, or pulling the lever on any one of the many virtual slot machines, is assigned a number from the RNG. So maybe a pair of sixes in a dice game corresponds to 673,467,527,656,14 or 8 Black on a roulette wheel to 574,862,745,879. The mathematical algorithm is different for every game and ensures that the numerical outcome always lines up with a possible outcome in the game.

Who Keeps Everything in Check?

In principle, RNGs sound great so far, but to ensure that the programs and algorithms are fair and legitimate, third-party organisations have to inspect and approve RNGs in order to keep players safe. In the EU, this is the Gambling Commission, whilst in the US, the authority varies by state, but in all cases, they ensure that RNGs meet a variety of criteria to be ‘acceptably random’. Indeed, there are organisations that constantly review systems to ensure that they are operating to the best of their ability. Regardless, legitimate gambling websites will display the contact details of these authorities and make their certificates available to be publicly viewed.

So next time you take part in an online casino game, you’ll have a better understanding of how these games work and know that you’re in the safe, fair hands of a randomly-generated string of digits!

The post How Do Random Number Generators Work? appeared first on Hacker Combat.

How Internet Security Evolved in Tandem with iGaming

For a non-biological entity, the internet is an area filled with constant and unstoppable evolution. From the hardware which backs it to the software systems it carries, nothing in this arena stays the same for long. One of the most major forms these changes take is seen in the world of security.

While there are many fields in which this battle is fought, by focusing on just one it can be possible to track greater trends in the online security environment. For the sake of this article, we want to use online bingo as an example. A simple game to play on the surface, it’s a world in which the real developments run surprisingly deep. Staying steady over the years, the invisible parts of such games are top of the class. But how did we get here?

A Change in Browsers

As this article by Popular Mechanics on Netscape Navigator can tell you, the earliest web browsers were incredibly simple. In some cases, the first browsers even had the option to disable all images from loading, to save on data costs. The problem with these browsers was that patches were few and far between, and limited expertise in developer security meant that malware was a constant concern.

my old naigator
My Old Navigator” (CC BY 2.0) by OiMax

This could have been problematic for the first browser bingo games, which appeared as early as 1996. To combat this issue, very specific locks were put into which browsers could access the first bingo offerings. Simply put, if a browser didn’t have the latest security tech, it wasn’t supported.

Over time, this security concern aided in the rise of online bingo which moved away from direct browser integration. Instead, many bingo games relied on downloadable clients from online casinos, which were much more tightly controlled, doing things many websites at the time couldn’t. These remained a standard for ages, only seeing significant abandonment recently.

The Modern Age

In the last few years, arguable the biggest change in online bingo gaming has come from improvements in HTML and related web technologies. HTML5, as a much more flexible system than its predecessors, has paved the way for bingo games to head back to browsers en force.

Take, for example, the games on Bingo Betfair online in UK areas. Thanks to modern tech, games like Housey Bingo and House of Mirrors are not just entirely safe on major websites, but they also run far faster and look far better than any old bingo games could. Not simply due to convenience, this change was also a matter of necessity.

Most online games used to operate within the system of Adobe Flash, which was the standard for many years. Yet Flash’s inbuilt limitations, including a growing potential for security flaws, put it on a road to obsolescence, as Time explains. This proved to major hurdle for some forms of entertainment, acting as a danger to online software without a proactive approach. Like most online casino games, bingo abandoned this system some time ago, but many still haven’t.

museum computer
Museum Computer” (CC BY 2.0) by Rd. Vortex

While just illustrating one small slice of the greater internet security landscape, online bingo points out some of the most major issues which occurred, and how they have been combatted. Sometimes, better security meant being demanding of browser standards, where other times it meant abandoning these systems entirely. Today, however, with systems as strict and advanced as they are, security and flexibility within browsers are the best they’ve ever been. Whatever might come next, if the past is any indication, bingo will reflect the best the web has to offer.

The post How Internet Security Evolved in Tandem with iGaming appeared first on Hacker Combat.

Ransomware attack on Garmin thought to be the work of ‘Evil Corp’

Russian cybercrime gang is believed to be responsible for taking Garmin services offline

A ransomware attack that took the GPS and smartwatch business Garmin entirely offline for more than three days is believed to have been carried out by a Russian cybercriminal gang which calls itself “Evil Corp”.

Garmin began to restore services to customers on Monday morning, after being held hostage for a reported ransom of $10m, although some services were still operating with limited functionality.

Ransomware is the most common form of criminal malware currently in use. Targets are commonly infected through malicious emails, which may trick them into downloading and running the software, or through exploiting vulnerabilities in other software such as Adobe Flash. When the ransomware program is activated, it encrypts the user’s hard drive with a single use encryption key, before flashing up a message asking for ransom, typically in the form of a payment in the cryptocurrency Bitcoin.

Related: Garmin down: how to still get your activities on to Strava

Continue reading...

NIST Launches Studies into Masks’ Effect on Face Recognition Software

Now that so many of us are covering our faces to help reduce the spread of COVID-19, how well do face recognition algorithms identify people wearing masks? The answer, according to a preliminary study by the National Institute of Standards and Technology (NIST), is with great difficulty. Even the best of the 89 commercial facial recognition algorithms tested had error rates between 5% and 50% in matching digitally applied face masks with photos of the same person without a mask. The results were published today as a NIST Interagency Report (NISTIR 8311), the first in a planned series from NIST

NICE Released the Summer 2020 eNewsletter

The Summer 2020 NICE eNewsletter has been published to provide subscribers information on academic, industry, and government developments related to the National Initiative for Cybersecurity Education (NICE), updates from key NICE programs, projects, the NICE Working Group, and other important news. To help increase the visibility of NICE, the NICE Program Office will issue regular eNewsletters that feature spotlight articles on academic, industry, and government developments related to NICE, updates from key NICE programs, projects, the NICE Working Group, and other important news. For

PSCR 2020: The Digital Experience

Since 2010, PSCR has held an annual Stakeholder Meeting to receive direct input, guidance, and feedback from public safety stakeholders across sectors. This information exchange has been invaluable to the success of the PSCR program and advancement of public safety communications technologies. That's why, in 2020, as part of our ongoing commitment to transparency, PSCR is developing a digital experience for sharing out yearly research updates. This new, virtual format will ensure stakeholders receive the cutting-edge updates they expect from PSCR delivered to wherever they are. When you claim

Smartwatch maker Garmin hit by outages after ransomware attack

US company forced to shut down call centres, website and some other online services

Garmin has been forced to shut down its call centres, website and some other online services after a ransomware attack encrypted the smartwatch maker’s internal network and some production systems.

The US company shut down services including the official Garmin website and all customer services, including phone lines, online chat and email.

Related: The five: ransomware attacks

Ransomware is the most common form of criminal malware currently in use. Targets are commonly infected through malicious emails, which may trick them into downloading and running the software, or through exploiting vulnerabilities in other software such as Adobe Flash. When the ransomware program is activated, it encrypts the user’s hard drive with a single use encryption key, before flashing up a message asking for ransom, typically in the form of a payment in the cryptocurrency Bitcoin.

Continue reading...

Towards native security defenses for the web ecosystem



With the recent launch of Chrome 83, and the upcoming release of Mozilla Firefox 79, web developers are gaining powerful new security mechanisms to protect their applications from common web vulnerabilities. In this post we share how our Information Security Engineering team is deploying Trusted Types, Content Security Policy, Fetch Metadata Request Headers and the Cross-Origin Opener Policy across Google to help guide and inspire other developers to similarly adopt these features to protect their applications.

History

Since the advent of modern web applications, such as email clients or document editors accessible in your browser, developers have been dealing with common web vulnerabilities which may allow user data to fall prey to attackers. While the web platform provides robust isolation for the underlying operating system, the isolation between web applications themselves is a different story. Issues such as XSS, CSRF and cross-site leaks have become unfortunate facets of web development, affecting almost every website at some point in time.

These vulnerabilities are unintended consequences of some of the web's most wonderful characteristics: composability, openness, and ease of development. Simply put, the original vision of the web as a mesh of interconnected documents did not anticipate the creation of a vibrant ecosystem of web applications handling private data for billions of people across the globe. Consequently, the security capabilities of the web platform meant to help developers safeguard their users' data have evolved slowly and provided only partial protections from common flaws.

Web developers have traditionally compensated for the platform's shortcomings by building additional security engineering tools and processes to protect their applications from common flaws; such infrastructure has often proven costly to develop and maintain. As the web continues to change to offer developers more impressive capabilities, and web applications become more critical to our lives, we find ourselves in increasing need of more powerful, all-encompassing security mechanisms built directly into the web platform.

Over the past two years, browser makers and security engineers from Google and other companies have collaborated on the design and implementation of several major security features to defend against common web flaws. These mechanisms, which we focus on in this post, protect against injections and offer isolation capabilities, addressing two major, long-standing sources of insecurity on the web.

Injection Vulnerabilities

In the design of systems, mixing code and data is one of the canonical security anti-patterns, causing software vulnerabilities as far back as in the 1980s. It is the root cause of vulnerabilities such as SQL injection and command injection, allowing the compromise of databases and application servers.

On the web, application code has historically been intertwined with page data. HTML markup such as <script> elements or event handler attributes (onclick or onload) allow JavaScript execution; even the familiar URL can carry code and result in script execution when navigating to a javascript: link. While sometimes convenient, the upshot of this design is that – unless the application takes care to protect itself – data used to compose an HTML page can easily inject unwanted scripts and take control of the application in the user's browser.

Addressing this problem in a principled manner requires allowing the application to separate its data from code; this can be done by enabling two new security features: Trusted Types and Content Security Policy based on script nonces.

Trusted Types
Main article: web.dev/trusted-types by Krzysztof Kotowicz

JavaScript functions used by developers to build web applications often rely on parsing arbitrary structure out of strings. A string which seems to contain data can be turned directly into code when passed to a common API, such as innerHTML. This is the root cause of most DOM-based XSS vulnerabilities.

Trusted Types make JavaScript code safe-by-default by restricting risky operations, such as generating HTML or creating scripts, to require a special object – a Trusted Type. The browser will ensure that any use of dangerous DOM functions is allowed only if the right object is provided to the function. As long as an application produces these objects safely in a central Trusted Types policy, it will be free of DOM-based XSS bugs.

You can enable Trusted Types by setting the following response header:
We have recently launched Trusted Types for all users of My Google Activity and are working with dozens of product teams across Google as well as JavaScript framework owners to make their code support this important safety mechanism.

Trusted Types are supported in Chrome 83 and other Chromium-based browsers, and a polyfill is available for other user agents.

Content Security Policy based on script nonces
Main article: Reshaping web defenses with strict Content Security Policy

Content Security Policy (CSP) allows developers to require every <script> on the page to contain a secret value unknown to attackers. The script nonce attribute, set to an unpredictable number for every page load, acts as a guarantee that a given script is under the control of the application: even if part of the page is injected by an attacker, the browser will refuse to execute any injected script which doesn't identify itself with the correct nonce. This mitigates the impact of any server-side injection bugs, such as reflected XSS and stored XSS.

CSP can be enabled by setting the following HTTP response header:
This header requires all scripts in your HTML templating system to include a nonce attribute with a value matching the one in the response header:
Our CSP Evaluator tool can help you configure a strong policy. To help deploy a production-quality CSP in your application, check out this presentation and the documentation on csp.withgoogle.com.

Since the initial launch of CSP at Google, we have deployed strong policies on 75% of outgoing traffic from our applications, including in our flagship products such as GMail and Google Docs & Drive. CSP has mitigated the exploitation of over 30 high-risk XSS flaws across Google in the past two years.

Nonce-based CSP is supported in Chrome, Firefox, Microsoft Edge and other Chromium-based browsers. Partial support for this variant of CSP is also available in Safari.

Isolation Capabilities

Many kinds of web flaws are exploited by an attacker's site forcing an unwanted interaction with another web application. Preventing these issues requires browsers to offer new mechanisms to allow applications to restrict such behaviors. Fetch Metadata Request Headers enable building server-side restrictions when processing incoming HTTP requests; the Cross-Origin Opener Policy is a client-side mechanism which protects the application's windows from unwanted DOM interactions.

Fetch Metadata Request Headers
Main article: web.dev/fetch-metadata by Lukas Weichselbaum

A common cause of web security problems is that applications don't receive information about the source of a given HTTP request, and thus aren't able to distinguish benign self-initiated web traffic from unwanted requests sent by other websites. This leads to vulnerabilities such as cross-site request forgery (CSRF) and web-based information leaks (XS-leaks).

Fetch Metadata headers, which the browser attaches to outgoing HTTP requests, solve this problem by providing the application with trustworthy information about the provenance of requests sent to the server: the source of the request, its type (for example, whether it's a navigation or resource request), and other security-relevant metadata.

By checking the values of these new HTTP headers (Sec-Fetch-Site, Sec-Fetch-Mode and Sec-Fetch-Dest), applications can build flexible server-side logic to reject untrusted requests, similar to the following:
We provided a detailed explanation of this logic and adoption considerations at web.dev/fetch-metadata. Importantly, Fetch Metadata can both complement and facilitate the adoption of Cross-Origin Resource Policy which offers client-side protection against unexpected subresource loads; this header is described in detail at resourcepolicy.fyi.

At Google, we've enabled restrictions using Fetch Metadata headers in several major products such as Google Photos, and are following up with a large-scale rollout across our application ecosystem.

Fetch Metadata headers are currently sent by Chrome and Chromium-based browsers and are available in development versions of Firefox.

Cross-Origin Opener Policy
Main article: web.dev/coop-coep by Eiji Kitamura

By default, the web permits some interactions with browser windows belonging to another application: any site can open a pop-up to your webmail client and send it messages via the postMessage API, navigate it to another URL, or obtain information about its frames. All of these capabilities can lead to information leak vulnerabilities:
Cross-Origin Opener Policy (COOP) allows you to lock down your application to prevent such interactions. To enable COOP in your application, set the following HTTP response header:
If your application opens other sites as pop-ups, you may need to set the header value to same-origin-allow-popups instead; see this document for details.

We are currently testing Cross-Origin Opener Policy in several Google applications, and we're looking forward to enabling it broadly in the coming months.

COOP is available starting in Chrome 83 and in Firefox 79.

The Future

Creating a strong and vibrant web requires developers to be able to guarantee the safety of their users' data. Adding security mechanisms to the web platform – building them directly into browsers – is an important step forward for the ecosystem: browsers can help developers understand and control aspects of their sites which affect their security posture. As users update to recent versions of their favorite browsers, they will gain protections from many of the security flaws that have affected web applications in the past.

While the security features described in this post are not a panacea, they offer fundamental building blocks that help developers build secure web applications. We're excited about the continued deployment of these mechanisms across Google, and we're looking forward to collaborating with browser makers and the web standards community to improve them in the future.

For more information about web security mechanisms and the bugs they prevent, see the Securing Web Apps with Modern Platform Features Google I/O talk (video).

NIST’s Post-Quantum Cryptography Program Enters ‘Selection Round’

The race to protect sensitive electronic information against the threat of quantum computers has entered the home stretch. After spending more than three years examining new approaches to encryption and data protection that could defeat an assault from a quantum computer, the National Institute of Standards and Technology (NIST) has winnowed the 69 submissions it initially received down to a final group of 15. NIST has now begun the third round of public review. This “selection round” will help the agency decide on the small subset of these algorithms that will form the core of the first post

Building the Federal Profile For IoT Device Cybersecurity: Next Steps for Securing Federal Systems

RECORDING: Captioning will be available by Monday, August 3, 2020. On July 22-23, NIST will host a virtual-only event, Building the Federal Profile For IoT Device Cybersecurity: Next Steps for Securing Federal Systems. NIST leveraged the Core Baseline established in NISTIR 8259A and analyzed the controls found in NIST SP 800-53 to develop a catalog of key IoT device cybersecurity capabilities and supporting non-technical manufacturer capabilities and associated IoT device customer controls. This catalog is a critical building block for establishing a federal profile of the Core Baseline (

US judge: WhatsApp lawsuit against Israeli spyware firm NSO can proceed

NSO Group was sued last year by messaging app owned by Facebook

An Israeli company whose spyware has been used to target journalists in India, politicians in Spain, and human rights activists in Morocco may soon be forced to divulge information about its government clients and practices after a judge in California ruled that a lawsuit against the company could proceed.

NSO Group was sued by WhatsApp, which is owned by Facebook, last year, after the popular messaging app accused the company of sending malware to 1,400 of its users over a two-week period and targeting their mobile phones.

Continue reading...

Spanish deputy PM urges investigation into Catalan spyware claims

Exclusive: Pablo Iglesias calls alleged targeting of independence movement figures unacceptable

The Spanish deputy prime minister, Pablo Iglesias, has become the most senior political figure to call for a parliamentary investigation into the use of spyware to target prominent members of the Catalan independence movement, saying such practices are “unacceptable in a democracy”.

A joint investigation this week by the Guardian and El País has revealed that Roger Torrent, the speaker of the Catalan parliament, and former regional foreign minister Ernest Maragall are among at least four pro-independence activists who have been targeted using Israeli spyware that its makers said is sold only to governments.

Continue reading...

I Did Not Write This Book


Fake Book
Fake Book 

Someone published a "book" on Amazon and claimed that I wrote it! I had NOTHING to do with this. I am working with Amazon now to remove it, or at least remove my name. Stay away from this garbage!

Update: Thankfully, within a day or so of this post, the true author of this work removed it from Amazon. It has not returned, at least as far as I have seen.

Introducing PhishingKitTracker

If you are a security researcher or even a passionate about how attackers implement phishing you will find yourself to look for phishing kits. A phishing kit is not a phishing builder, but a real implementation (actually re-implementation) of a third party website built to lure your victim. Initially attackers use a phishing builder to “clone” the original web site but after that they introduce – in the fresh re-generate website – interesting ad-dons such as for example: evasion techniques (in order to evade to phishing detectors), targeted elements (in order to targetize the victims), fast re-directors ( to follows the attack chain into the original web-site or to a relay to try to infect you) and sometimes exploit-kits to try to exploit your browser before letting you go.

Credit: Alen Pavlovic (here)

Motivation

There are places where you can buy PhishingKits, for example BleepingComputer wrote a great article on that here, but if you want to get them for free in order to study attack schema and Kit-composition you don’t’ find collections for free. So I decided to share my PhishingKit Tracker, updated automatically by my backend engine every day for study and research purposes.

You can find it HERE (PhishingKitTracker github repo)

Disclaimer

This repository holds a collection of Phishing Kits used by criminals to steal user information. Almost every file into the raw folder is malicious so I strongly recommend you to neither open these files, nor misuse the code to prank your friends. Playing with these kits may lead to irreversible consequences which may affect anything from personal data to passwords and banking information.

I am not responsible for any damage caused by the malware inside my repository and your negligence in general.

NB: Large File System Hahead

PhishingKitTracker is stored into Git Large File System (git-lfs) due to the big amount of data tracked. You should install git-lfs before cloning this repository.

RAW Data

In raw folder are tracked the Phishing Kits in the original format. No manipulation are involved in that data. A backend script goes over malicious harvested websites (harvesting from common sources) and checks if Phishing Kits are in there. In a positive case (if a PhishingKit is found) the resulting file is downloaded and instantly added to that folder. This folder is tracked by using Git Large File System since many files are bigger than 100MB. The “RAW Data” is a quite unexplored land, you would find many interesting topics with high probability. Please remember to cite that work if you find something from here, it would be very appreciated.

STATS

In stats folder are maintained two up-to-date files:

  1. files_name it holds the frequency of the found file-names associate with kits. In other words every phishing kit is saved on the phishing host with a name. filke_name keeps track about every file names and its frequency. If you are wondering why am I not tracking hashes, is because phishing kits are big compressed archives, so it would make no sense at this stage since they always differ each other (but check in src folder for additional information)
  2. sites hols the frequency of the hosting domain names. In other words where the phishing kit was found. No duplicates are tracked by meaning that the frequency and the file names are unique. So for example if you see something like: 3 li.humanbiomics-project.org it means that in li.humanbiomics-project.org have been found three different Phishing Kits over time.

Both of these files have been generate by simple bash scripts like:

  • ls raw/ | cut -d'_' -f1 | uniq -c | sort -bgr > stats/sites.txt
  • ls raw/ | cut -d'_' -f2 | uniq -c | sort -bgr > stats/files_name.txt

these scripts are run on every commit making files inline with the raw folder.

On the other side a file called similarity.csv is provided with a tremendous delay due to the vast amount of time in generating it. That file provides the similarity between the tracked Phishing Kits. It’s a simple CSV file so that you can import it on your favorite spreadsheet and make graphs, statistics or manipulate it in the way you prefer.

SIMILARITY.CSV structure

The similarity structure is like the following one: FileA,FileB,SimilarityAVG,SimilarityMin,SimilarityMax where:

  • FileA is PhishingKit which is considered in that analysis.
  • FileB is the PhishingKit to be compared to PhishingKit FileA
  • SimilarityAVG is the Average in similarity. That average is calculated by computing the similarity check to every single (interesting) file in the PhishingKit archive (FileA) to every single (interesting) file in the PhishingKit archive to be compared (FileB)
  • SimilarityMin is the lowest similarity value found between PhishingKitA and PhishingKitB
  • SimilarityMax is the highest similarity value found between PhishingKitA and PhishingKitB

If you want to generate similarity.csv by your own I provide a simple and dirty script into the src folder. So far it has several limitations (for example it computes ZIP only files). please make pull requests for improving and empower it. Each contribute would be very helpful.

SRC

Please check those variables (compute_similarity.py) and change them at your will.

EXTENSION_FOR_ANALYSIS = ['.html','.js','.vbs','.xls','.xlsm','.doc','.docm', '.ps1']
OUTPUT_FILE =  'similarity.csv'                                                 
RAW_FOLDER = '/tmp/raw/'                                                        
TEMP_FOLDER = '/tmp/tt'     

Once you’ve changed them you can run the script and take a long rest. It will navigate through the RAW_FOLDER, grab the .zip files and tries to compute code similarity between them. At the very end it will save results into OUTPUT_FILE. From now you can import such a a file into your favorite spreadsheet processor and elaborate the code similarity.

So far the python script is able to only compare zip tracked phishingkit, for different compressed format it’s still work in progress.

NB: The Python script is in a super early stage of development. Please help to improve it.

How to contribute

Introducing the walking script for different compression formats. In other words if you want to contribute you can write a new section such as the following one (code_similarity.py) but for different compression extensions such as: .tar.gz, .tar, .rar. /7z and so on and so forth.

# Extracts Zip files based on EXTENSION_FOR_ANALYSIS. It returns the etire file
# path for future works
def extractZipAndReturnsIntereistingFiles(file_to_extract):
    interesting_files = []
    n_interesting_files = []
    try:
        with ZipFile(file_to_extract, 'r') as zipObj:
            listOfFileNames = zipObj.namelist()
            for fileName in listOfFileNames:
                for ext in EXTENSION_FOR_ANALYSIS:
                    if fileName.endswith(ext):
                        try:
                            zipObj.extract(fileName, TEMP_FOLDER)
                            interesting_files.append(os.path.join(TEMP_FOLDER, fileName))
                        except Exception as e:
                            continue
                    else:
                        n_interesting_files.append(os.path.join(TEMP_FOLDER, fileName))
    except Exception as e :
        return interesting_files
    return interesting_files

One more way to contribute is to make the comparison loop smarter and quicker. You might decide to parallelized task by forking and spawning more process or by changing the way I use multi-threading in this quick and dirty statistic script. In conclusion every working pull is welcomed.

Cite the Phishing Kit

@misc{ MR,
       author = "Marco Ramilli",
       title = "Phishing Kits Tracker",
       year = "2020",
       url = "https://marcoramilli.com/2020/07/13/introducing-phishingkittracker/",
       note = "[Online; July 2020]"
     }

SCANdalous! (External Detection Using Network Scan Data and Automation)

Real Quick

In case you’re thrown by that fantastic title, our lawyers made us change the name of this project so we wouldn’t get sued. SCANdalous—a.k.a. Scannah Montana a.k.a. Scanny McScanface a.k.a. “Scan I Kick It? (Yes You Scan)”—had another name before today that, for legal reasons, we’re keeping to ourselves. A special thanks to our legal team who is always looking out for us, this blog post would be a lot less fun without them. Strap in folks.

Introduction

Advanced Practices is known for using primary source data obtained through Mandiant Incident Response, Managed Defense, and product telemetry across thousands of FireEye clients. Regular, first-hand observations of threat actors afford us opportunities to learn intimate details of their modus operandi. While our visibility from organic data is vast, we also derive value from third-party data sources. By looking outwards, we extend our visibility beyond our clients’ environments and shorten the time it takes to detect adversaries in the wild—often before they initiate intrusions against our clients.

In October 2019, Aaron Stephens gave his “Scan’t Touch This” talk at the annual FireEye Cyber Defense Summit (slides available on his Github). He discussed using network scan data for external detection and provided examples of how to profile command and control (C2) servers for various post-exploitation frameworks used by criminal and intelligence organizations alike. However, manual application of those techniques doesn’t scale. It may work if your role focuses on one or two groups, but Advanced Practices’ scope is much broader. We needed a solution that would enable us to track thousands of groups, malware families and profiles. In this blog post we’d like to talk about that journey, highlight some wins, and for the first time publicly, introduce the project behind it all: SCANdalous.

Pre-SCANdalous Case Studies

Prior to any sort of system or automation, our team used traditional profiling methodologies to manually identify servers of interest. The following are some examples. The success we found in these case studies served as the primary motivation for SCANdalous.

APT39 SSH Tunneling

After observing APT39 in a series of intrusions, we determined they frequently created Secure Shell (SSH) tunnels with PuTTY Link to forward Remote Desktop Protocol connections to internal hosts within the target environment. Additionally, they preferred using BitVise SSH servers listening on port 443. Finally, they were using servers hosted by WorldStream B.V.

Independent isolation of any one of these characteristics would produce a lot of unrelated servers; however, the aggregation of characteristics provided a strong signal for newly established infrastructure of interest. We used this established profile and others to illuminate dozens of servers we later attributed to APT39, often before they were used against a target.

APT34 QUADAGENT

In February 2018, an independent researcher shared a sample of what would later be named QUADAGENT. We had not observed it in an intrusion yet; however, by analyzing the characteristics of the C2, we were able to develop a strong profile of the servers to track over time. For example, our team identified the server 185.161.208\.37 and domain rdppath\.com within hours of it being established. A week later, we identified a QUADAGENT dropper with the previously identified C2. Additional examples of QUADAGENT are depicted in Figure 1.


Figure 1: QUADAGENT C2 servers in the Shodan user interface

Five days after the QUADAGENT dropper was identified, Mandiant was engaged by a victim that was targeted via the same C2. This activity was later attributed to APT34. During the investigation, Mandiant uncovered APT34 using RULER.HOMEPAGE. This was the first time our consultants observed the tool and technique used in the wild by a real threat actor. Our team developed a profile of servers hosting HOMEPAGE payloads and began tracking their deployment in the wild. Figure 2 shows a timeline of QUADAGENT C2 servers discovered between February and November of 2018.


Figure 2: Timeline of QUADAGENT C2 servers discovered throughout 2018

APT33 RULER.HOMEPAGE, POSHC2, and POWERTON

A month after that aforementioned intrusion, Managed Defense discovered a threat actor using RULER.HOMEPAGE to download and execute POSHC2. All the RULER.HOMEPAGE servers were previously identified due to our efforts. Our team developed a profile for POSHC2 and began tracking their deployment in the wild. The threat actor pivoted to a novel PowerShell backdoor, POWERTON. Our team repeated our workflow and began illuminating those C2 servers as well. This activity was later attributed to APT33 and was documented in our OVERRULED post.

SCANdalous

Scanner, Better, Faster, Stronger

Our use of scan data was proving wildly successful, and we wanted to use more of it, but we needed to innovate. How could we leverage this dataset and methodology to track not one or two, but dozens of active groups that we observe across our solutions and services? Even if every member of Advanced Practices was dedicated to external detection, we would still not have enough time or resources to keep up with the amount of manual work required. But that’s the key word: Manual. Our workflow consumed hours of individual analyst actions, and we had to change that. This was the beginning of SCANdalous: An automated system for external detection using third-party network scan data.

A couple of nice things about computers: They’re great at multitasking, and they don’t forget. The tasks that were taking us hours to do—if we had time, and if we remembered to do them every day—were now taking SCANdalous minutes if not seconds. This not only afforded us additional time for analysis, it gave us the capability to expand our scope. Now we not only look for specific groups, we also search for common malware, tools and frameworks in general. We deploy weak signals (or broad signatures) for software that isn’t inherently bad, but is often used by threat actors.

Our external detection was further improved by automating additional collection tasks, executed by SCANdalous upon a discovery—we call them follow-on actions. For example, if an interesting open directory is identified, acquire certain files. These actions ensure the team never misses an opportunity during “non-working hours.” If SCANdalous finds something interesting on a weekend or holiday, we know it will perform the time-sensitive tasks against the server and in defense of our clients.

The data we collect not only helps us track things we aren’t seeing at our clients, it allows us to provide timely and historical context to our incident responders and security analysts. Taking observations from Mandiant Incident Response or Managed Defense and distilling them into knowledge we can carry forward has always been our bread and butter. Now, with SCANdalous in the mix, we can project that knowledge out onto the Internet as a whole.

Collection Metrics

Looking back on where we started with our manual efforts, we’re pleased to see how far this project has come, and is perhaps best illustrated by examining the numbers. Today (and as we write these continue to grow), SCANdalous holds over five thousand signatures across multiple sources, covering dozens of named malware families and threat groups. Since its inception, SCANdalous has produced over two million hits. Every single one of those, a piece of contextualized data that helps our team make analytical decisions. Of course, raw volume isn’t everything, so let’s dive a little deeper.

When an analyst discovers that an IP address has been used by an adversary against a named organization, they denote that usage in our knowledge store. While the time at which this observation occurs does not always correlate with when it was used in an intrusion, knowing when we became aware of that use is still valuable. We can cross-reference these times with data from SCANdalous to help us understand the impact of our external detection.

Looking at the IP addresses marked by an analyst as observed at a client in the last year, we find that 21.7% (more than one in five) were also found by SCANdalous. Of that fifth, SCANdalous has an average lead time of 47 days. If we only consider the IP addresses that SCANdalous found first, the average lead time jumps to 106 days. Going even deeper and examining this data month-to-month, we find a steady upward trend in the percentage of IP addresses identified by SCANdalous before being observed at a client (Figure 3).


Figure 3: Percentage of IP addresses found by SCANdalous before being marked as observed at a client by a FireEye analyst

A similar pattern can be seen for SCANdalous’ average lead time over the same data (Figure 4).


Figure 4: Average lead time in days for SCANdalous over the same data shown in Figure 3

As we continue to create signatures and increase our external detection efforts, we can see from these numbers that the effectiveness and value of the resulting data grow as well.

SCANdalous Case Studies

Today in Advanced Practices, SCANdalous is a core element of our external detection work. It has provided us with a new lens through which we can observe threat activity on a scale and scope beyond our organic data, and enriches our workflows in support of Mandiant. Here are a few of our favorite examples:

FIN6

In early 2019, SCANdalous identified a Cobalt Strike C2 server that we were able to associate with FIN6. Four hours later, the server was used to target a Managed Defense client, as discussed in our blog post, Pick-Six: Intercepting a FIN6 Intrusion, an Actor Recently Tied to Ryuk and LockerGoga Ransomware.

FIN7

In late 2019, SCANdalous identified a BOOSTWRITE C2 server and automatically acquired keying material that was later used to decrypt files found in a FIN7 intrusion worked by Mandiant consultants, as discussed in our blog post, Mahalo FIN7: Responding to the Criminal Operators’ New Tools and Techniques.

UNC1878 (financially motivated)

Some of you may also remember our recent blog post on UNC1878. It serves as a great case study for how we grow an initial observation into a larger set of data, and then use that knowledge to find more activity across our offerings. Much of the early work that went into tracking that activity (see the section titled “Expansion”) happened via SCANdalous. The quick response from Managed Defense gave us just enough information to build a profile of the C2 and let our automated system take it from there. Over the next couple months, SCANdalous identified numerous servers matching UNC1878’s profile. This allowed us to not only analyze and attribute new network infrastructure, it also helped us observe when and how they were changing their operations over time.

Conclusion

There are hundreds more stories to tell, but the point is the same. When we find value in an analytical workflow, we ask ourselves how we can do it better and faster. The automation we build into our tools allows us to not only accomplish more of the work we were doing manually, it enables us to work on things we never could before. Of course, the conversion doesn’t happen all at once. Like all good things, we made a lot of incremental improvements over time to get where we are today, and we’re still finding ways to make more. Continuing to innovate is how we keep moving forward – as Advanced Practices, as FireEye, and as an industry.

Example Signatures

The following are example Shodan queries; however, any source of scan data can be used.

Used to Identify APT39 C2 Servers

  • product:“bitvise” port:“443” org:“WorldStream B.V.”

Used to Identify QUADAGENT C2 Servers

  • “PHP/7.2.0beta2”

RULER.HOMEPAGE Payloads

  • html:“clsid:0006F063-0000-0000-C000-000000000046”

The Cyber Security Guide For Small Business Owners

Cybercrime isn’t limited to large corporations or wealthy individuals; it also targets small businesses. According to the U.S. Congressional Small Business Committee, a significant amount of cyber-attacks targeted businesses with less than 100 workers. A related study by the SMB CyberSecurity Report established that 50% of SMBs had experienced a security breach in the past.

The reason small businesses are targeted more than large corporations is that they’ve vulnerabilities in their networks. This means it’s easier to breach the networks of small businesses than it’s to penetrate large corporations. Small businesses don’t allocate sufficient time and funds to secure their networks. They also lack expert personnel, have outdated security programs, and fail to secure their endpoints. The following are some of the basic cybersecurity best practices for small businesses.

Use a Firewall

Setting up a firewall is one of the basic ways of defending your business against a cyber-attack. The Federal Communications Commission urges small businesses to have firewalls to prevent data breaches. Some organizations have a standard firewall and an internal firewall for additional protection. Employees working remotely should also set up firewalls on their home networks.

Put Your Cybersecurity Policies In Writing

When it comes to cybersecurity, it’s advisable to put your policies in writing. To get started, you can attend online training through the Small Business Administration Cybersecurity portal. You can get help with drafting your policies from the FCC’s Cyberplanner 2.0. Alternatively, you can request a comprehensive toolkit for cybersecurity best practices through the C3 Voluntary Program for Small Businesses.

Use The CIA Model

When it comes to establishing cybersecurity policies, you should use the CIA model to guide you. This model helps keep your business secure by protecting your data. The elements of this model are Confidentiality, Integrity, and Availability. First, you should make sure information can’t be accessed by unauthorized personnel. You can do this by encrypting the information.

Secondly, you need to protect data and systems from being altered by unauthorized personnel. This means you should ensure that the information is unchanged from the time you create it to the time it reaches the end-user. Lastly, ensure authorized personnel have access to information when they need it and that you update your applications whenever necessary.

Train Employees In Cyber Security Measures

After you have established security policies, the next step is to train your employees on how to incorporate these measures. For example, you should train your employees on how to create strong passwords. It would help if you also established rules that penalize employees for violating the business’s Cybersecurity policies. Make ground rules on how to manage and protect client data and other important information. For example, you may establish rules that all machines should have the latest security software, operating system, and web browser to guard against malware, viruses, and online threats.

Device a Plan For Mobile Devices

According to Tech Pro Research 2016 BYOD, 59% of businesses allow BYOD. There’s a high surge in the use of wearables like wireless fitness trackers and smartwatches. For this reason, small businesses should establish BYOD policies that emphasize the need for security precautions. Norton by Symantec also urges small businesses to encourage employees to set automatic updates and use a strong password policy for mobile devices that are tapping into the company’s network.

Back up Your Data Regularly

You may still be breached after observing all the necessary security measures. This is why you need to back up data regularly. You also need to back up data that is kept in the cloud because those servers could also be compromised. Store your backups in a safe place to guard against fire outbreaks and floods. Make sure your backups are up to date.

Apply Multifactor Identification

No matter how secure you think you’re, mistakes are inevitable. An employee can make a mistake that leaves your network vulnerable. Using the multifactor identification settings provides an additional layer of protection to your network. You can use employees’ phone numbers because it would be unlikely for a cybercriminal to have both the pin code and the password.

Secure Your Wi-Fi Network

If your business has a Wi-Fi network, you need to secure it. Encrypt and hide the Wi-Fi network, so it’s not accessed by unauthorized personnel. To hide the network, set up a wireless access point to prevent it from broadcasting the name of the network, also called the Service Set Identifier (SSID). Protect access to the router using a password. 

Endnote

Many businesses downplay the threat of cybercriminals, arguing that they don’t have significant assets or that their data is not worth a security breach. However, cybercriminals target the weak networks of small businesses more than the heavily secured networks of large organizations. For this reason, it’s important to observe cybersecurity practices to ensure your business and clients are secured from cyber thieves. The above measures will help you tighten the data security of your organization, making it more difficult for hackers to breach your systems.

The post The Cyber Security Guide For Small Business Owners appeared first on CyberDB.

8 Types of Security Threats to the IoT

Introduction

The IoT industry is currently booming at a rapid scale, allowing for insights backed by data to provide value to industries and enterprises. For instance, in supply chain, IoT is helping track the exact locations and condition of the cargo shipments to ensure that goods in transportation safely reach their destination. In agricultural sector, IoT devices help farmers to monitor changes in weather near crop fields to enhance labor, harvest health and water usage. Travel industry is making use of IoT sensors to notify on-arrival passengers when their luggage reaches the airport.

These and many more opportunities offered by IoT are making our lives easier and provide us with limitless services to enable increased work productivity and efficiency. However, its adoption is still not as widespread as anticipated. The reason is the security obstacles associated with IoT devices. In the year 2018, according to a survey by Bain & Company, security was the top reason for industrial and enterprise respondents to not adopt IoT technology. These security challenges can be overcome, but to understand how to do that, it’s important to first know what these challenges are.

Let us look at some of the many security threats faced by the Internet of Things.

  1. Radio Frequency (RF) Jamming

Hackers can use radio jamming to block wireless IoT devices by interfering with wireless communications to hinder their functionality. This can be done by getting hold of an RF Jammer, causing IoT devices to limit their communication ability by losing connectivity. For instance, residential and commercial wireless security alarms that are connected over a cellular network can be easily jammed and enable an intruder to break in without the knowledge of the security provider.

  • Distributed Denial of Service (DDoS) Attacks

A DDoS attack happens when all network devices are precariously made to send limitless messages that eventually cause congestion in the IoT network shut it down. Cyber criminals use DDoS attacks to control numerous compromised devices, thus preventing important information from reaching its destination.

  • Privacy Leakage

An unsecured IoT device that leaks its IP address, if identified by a hacker, can be misused to point to any location. It is recommended that IoT connections should be secured using Virtual Private Networks (VPNs). Just as an Internet Service Provider’s network can be secured by  installing VPN on a router to encrypt all traffic passing through (see HughesNet Internet for the best satellite internet services), the same can be applied to an IoT device to ensure that your IP is private and your smart network is protected.

  • Network Hacks

A network hack takes place when an IoT device is compromised through the network that it is connected to. This kind of security breach allows a hacker to access and control the device. For instance, they can gain control of the thermostat of an industrial furnace and start a fire or cause an autonomous vehicle to crash by controlling its driving.

  • Home Intrusion

This is one of the reasons why smart homes are not ideally seen as a reality and adapted far and wide till now. It is also one of the scariest scenarios which can turn a device meant for an individual customer’s convenience into a major threat to their home privacy. Unsecured IoT devices that are shipped to a user with default username as ‘admin’ and password as ‘12345’ are very vulnerable to home intrusion. This can not only be used in planned burglaries but also invades complete privacy of a residential household. This is why it’s very important to secure a device’s credentials and connect them through a VPN.

  • Lack of Device Updates

Companies are manufacturing IoT devices at an increasing rate due to the growing demand. However, since their focus is on production and competition, manufacturers are not very careful with handling IoT device-related risks and security issues. Many of the devices in the market do not have considerable security updates, and some of them are never updated at all. Even if a device initially caters to security requirements, it becomes insecure and vulnerable after the emergence of new technologies and new cyber security challenges, making it more prone to cyber-attacks, especially if it is not updated.

Some manufacturers deliver Over the Air (OTA) firmware updates but stop doing that once they start working on next generation devices, thus leaving the older devices exposed to security threats. 

  • Unsafe Communication

Most of the IoT devices do not encrypt messages while communicating over a network, which makes it one of the biggest security challenges of IoT. To prevent from intrusion, companies need to secure and encrypt their communication between cloud services and devices. Using transport encryption and standards such as TLS can ensure safe communication. Also, device isolation using different networks can ensure a secure private communication.

  • Difficulty in Determining a Device’s Compromised Status

Another one of the challenges of an IoT device is that it is very hard to ascertain if a device is hacked or not.  Especially when there are a large number of IoT devices, it gets very difficult to monitor the security status of all the devices. This is because IoT devices need services, apps and protocols to communicate; and with more devices, it’s becoming unmanageable to find out which of them are compromised. As a result, many such hacked devices continue to work without the user’s knowledge and their data and privacy keeps getting compromised.

The Bottom Line

There is no doubt that IoT promises a change that can bring more convenience to our lives and is destined to get bigger with time. However, the bigger it is going to get, the more headaches it will progressively carry along with itself as the accompanying IoT trends and threats also get bigger. This can only be overcome if device manufacturers and IoT industry stakeholders take security seriously and make it a top priority instead of joining a competitive race towards more production and short-term profits.

The post 8 Types of Security Threats to the IoT appeared first on CyberDB.

NIST Kick-Starts ‘Threshold Cryptography’ Development Effort

A new publication by cryptography experts at the National Institute of Standards and Technology (NIST) proposes the direction the technical agency will take to develop a more secure approach to encryption. This approach, called threshold cryptography, could overcome some of the limitations of conventional methods for protecting sensitive transactions and data. The document, released today in a final version as NIST Roadmap Toward Criteria for Threshold Schemes for Cryptographic Primitives (NISTIR 8214A), offers an outline for developing a new way to implement the cryptographic tools that

Cyber Threats Trends 6 Months Of Findings

After six months from Cyber Threats Trends launch it’s time to check its main findings. When I decided to develop my own Cyber Threats Observatory I was not sure about its effectiveness and I was even more skeptical about the real usage from international cybersecurity communities. Fortunately many students, researchers and professionals used such a data to write thesis, papers and researches. Many of them cited my work (by adding a link in footnotes or in the reference section), other just dropped a “thank you email”. This was enough for me to decide to mantain Cyber Threats Trends for additional six months. Performing data collection, data analysis and data classification requires a quite expensive back-end, so it needs to be useful for somebody otherwise it would make no sense to maintain such a dedicated infrastructure.

But now let’s take a looks to what it was able to find during the past six months.

Malware Families

The most seen Malware families from January 2020 to June 2020 (6 months of activity) are the following ones:
GrandCrab ~3%
Upatre ~1,9% (!!)
Emotet ~1,8%
TrickBot ~1,25%
It looks like be inline with many available statistics and reports from the 2020 with the only exception on Upatre, which looks like super out of topic in 2020, but I have mostly discussed it here, so today I am quite confident it’s not a wrong classification. Many other families have been seen according to the following graph, but they will not be discussed in the current post.

Malware Families

Looking at the distribution of the top malware families we might focus on figure-out if some temporal pattern would emerge. The following image shows the GrandCarb family distribution over time. It is interesting to see that GrandCrab was mostly active during the last two weeks of March reaching its top detection rate on 2020-03-31 within a delicious frequency rate about 138 unique “findings” in that single day. Contrary it looks like to be less used during the months of May and June 2020.

GandCrab was a Ransomware-as-a-Service (RaaS) emerged in January 28, 2018, managed by a criminal organization known to be confident and vocal, while running a rapidly evolving ransomware campaign. Through their aggressive, albeit unusual, marketing strategies and constant recruitment of affiliates, they were able to globally distribute a high volume of their malware.

From Malpedia

Looking at pattern-wise we might agree there is a kind of frequency inside of it. If you group the date by weeks you might find that GrandCrab is mostly used twice per month. If you consider a “top” (the biggest local maximum detection rate) as the campaign launching day and the following local maximum tops in detection rate (in other words the shorter “tops” or the local maximums) as physiological campaign adjustments, it looks like attackers would take two weeks to harvest profit from previous launched campaign and to prepare new artifacts for the following one.

GrandCrab Ditribution over time

The following graph shows the Upatre family distribution over the past six months.

First discovered in 2013, Upatre is primarily a downloader tool responsible for delivering additional trojans onto the victim host. It is most well-known for being tied with the Dyre banking trojan, with a peak of over 250,000 Upatre infections per month delivering Dyre back in July 2015. In November 2015 however, an organization thought to be associated with the Dyre operation was raided, and subsequently the usage of Upatre delivering Dyre dropped dramatically, to less than 600 per month by January 2016.

From Paloalto Unit42

This is a very interesting graph because Upatre was not longer used since years (I bet since 2016). However it looks like attackers recovered it and re-started to use it from April 2020. Grouping by date you would appreciate a 3 days rhythm meaning that from one “attack wave” to another one it would take an average of 3 days. I will perform additional check on that, but static rules are perfectly matching what we are seeing int the upatre graph.

Upatre Distribution over time

Moving one TrickBot, the following image shows its distribution over time. TrickBot was mostly active during the first months of 2020 in a constant and linear way, while from March to April 2020 it experienced a quite significant speedup. Due to covid thematic campaigns Cyber Threats Trends recorded more TrickBot as never before in such time frame.

A financial Trojan believed to be a derivative of Dyre: the bot uses very similar code, web injects, and operational tactics. Has multiple modules including VNC and Socks5 Proxy. Uses SSL for C2 communication.

From Malpedia
TrickBot Distribution over time

The following image shows the Emotet Distribution over time. As plausible the Emotet’s distribution follows the TrickBot one. Even if it is not clear the relationship between TrickBot folks and Emotet folks, we are quite accustomed to see these frameworks closely delivered in common campaigns, like for example few months ago when we experienced a lot of Ryuk (ransomware) distribution using Emotet + TrickBot.

While Emotet historically was a banking malware organized in a botnet, nowadays Emotet is mostly seen as infrastructure as a service for content delivery. For example, since mid 2018 it is used by Trickbot for installs, which may also lead to ransomware attacks using Ryuk, a combination observed several times against high-profile targets.

From Malpedia
Emotet Distribution

Some indicators, such as the detection rate in January and the detection rate in June show to us that Emotet is used on these specific months even without TrickBot and it might suggest a different attack delivery procedure highlighting a different threat actor. In other words, comparing TrickBot and Emomet we observe that there are mainly two groups: a group which delivers TrickBot and Emotet together (such as the Ryuk ransom group) and a group which uses Emotet without TrickBot.

Carrier Distribution

Excluding the file type exe, which is the most analyzed file extension in the dropper panorama, we continue to observe many office files as the main Malware carrier. For example Microsoft Word Document within MACRO files are the most observed Malware carrier followed by PDF documents and CDF contents. While PowerShell files are still one of the most emerging threats we have not observed vast amount of Malware delivery on such carrier so far, but we see a revamping in the ancient Microsoft Excel Macro 4.0 as obfuscation technique.

Frequency no EXE

Still quite interesting how that statistics change over time. Indeed PDF and OLE objects are still the most used during the analyzed period of time. Even CDF document are quite common while simple scripts such as “VBscript” of Javascript are slowly decelerate their presence in international statistics.

Conclusion

Developing Cyber Threats Trends has been a great journey ! I had many sleepless nights and additional costs due to a quite big backend network (especially “database speaking”) but I had the opportunity to collect super interesting data and to increase knowledge on malware statistics and on developing distributed systems. Moreover it turned out being a quite useful data collection and trend analysis tool for quite few people out there ! I would definitely keep it on collecting more data !