❌

Reading view

There are new articles available, click to refresh the page.

VerSprite and AppSecEngineer Partner to Operationalize Security Training

✇VerSprite
bigdrop

Full-stack, comprehensive, and affordable security training Today, leading cybersecurity service provider VerSprite and security training leader AppSecEngineer announce a partnership to operationalize security training. The joint effort will result in a comprehensive full-stack security training program...

The post VerSprite and AppSecEngineer Partner to Operationalize Security Training appeared first on Versprite.

Why Bad Guys do Bad Things: How Maslow’s Hierarchy of Needs can help identify cyber threats.

✇VerSprite
bigdrop

Daniel Stiegman Principal Intelligence Analyst – Threat Intelligence Group at VerSprite Why does crime happen? Cyber security professionals can be so invested in answering the “How?” or the “What?” that occurred in a cyber incident, that...

The post Why Bad Guys do Bad Things: How Maslow’s Hierarchy of Needs can help identify cyber threats. appeared first on Versprite.

The Rise of AI in Cybersecurity: Expert Insights on the Benefits and Challenges of ChatGPT

✇VerSprite
VerSprite

As artificial intelligence (AI) continues to revolutionize our technology interaction, businesses are turning to AI-powered tools such as ChatGPT to improve their operations and enhance customer experiences. However, with this increased adoption of AI comes a greater need for cybersecurity professionals to ensure these tools are used safely and responsibly.  In this article, we interview …

Continue reading "The Rise of AI in Cybersecurity: Expert Insights on the Benefits and Challenges of ChatGPT"

The post The Rise of AI in Cybersecurity: Expert Insights on the Benefits and Challenges of ChatGPT appeared first on VerSprite.

A Look at RACI Models within Application Threat Modeling

✇VerSprite
bigdrop

Application threat modeling is known to be one of the most effective cybersecurity frameworks. A common question we receive is who should be involved in conducting application threat models.

VerSprite developed a RACI model, which depicts who is Responsible, Accountable, Consulted, and/or Informed as part of the overall threat modeling process. VerSprite customized a RACI model to align with the PASTA threat modeling methodology to bring clarity and a better understanding of where the responsibilities lie across an organization. RACI is a role distribution diagram that helps companies adopt threat modeling while leveraging the roles within an organization and its InfoSec department. It is a straightforward visual to save your team time and resources.

PASTA RACI Diagram

Why is RACI important?

RACI is important in threat modeling in order to build a workflow where there are multiple beneficiaries and stakeholders to a threat modeling process. The risk-centric threat modeling approach of PASTA goes through seven stages where multiple stakeholders will contribute or receive deliverables/ inputs from each stage.  This helps to ensure that the process is both meaningful and effective in building a model of threats for a given application or product.  When everyone involved understands their role in the security and how they can contribute, it makes the threat modeling implementation and sustaining more effective.

In a recent video, Tony UcedaVelez, VerSprite’s CEO and Founder, expands on the importance of the role distribution in cybersecurity:

“It’s surprising to see that no other approach in application threat modeling has constructed a RACI model for other types of approach (e.g. – security centric, software centric, etc.).  VerSprite has spent time to develop the RACI model based upon its interactions with product development teams across various industries.”

RACI Use Cases in PASTA

The security of application does not just rely on code itself. It relies on design, the infrastructure, and the platform or frameworks that it is running on. Oftentimes, threat modeling conversations are not factoring in all these different components, especially the people that have jurisdiction or stewardship over those technologies or efforts.

For example, in threat modeling, during dataflow diagraming exercise, you have developers that call out dataflows that are part of the software model. However, the architects, engineers, business analysts, or even the project managers, that are involved early on in defining requirements for the business are often not factored in. This is why it is so important to make application threat modeling very collaborative and to be an effort that many people can come to the table on.

Quality assurance engineers typically focus on the functional testing. With the role distribution RACI offers, many of them now have an opportunity to also run security unit tests, especially as part of sprints. This becomes really important because quality assurance engineers are able to run some security scripts that are developed by, for example, a DevSecOps group.

One important role that oftentimes gets overlooked is architect, who is responsible for architecting the overall design and patterns to be used and abided by the software product. Many developers are not architects and they simply focus on developing software that relates to their modular component of the product. The architect has the responsibility of overseeing the process and understanding what types of possible permission roles, dataflows, requirements by the business, and compliance laws that should be supported for the overall application model. Not inviting the architect is a major oversight, and in many threat-modeling activities and methodologies you don’t have the inclusion of the architect at all.

Final Thoughts and Prescriptive Advice

It should be mentioned that it is not an obligation to have all of this community of individuals come together and build a threat model. That would be very time consuming. The advantage of using RACI is having a set and efficient way to get either byproduct from each of these constituents, roles, and responsibilities to be used and leveraged, or to get their direct input into the threat model. The overall participation of some of these individuals makes for a better threat model. The better the input, the better the values that go into the understanding of flows, dependencies, the attack surfaces, threats, or threat intel. There are many pieces of information that can be derived by individuals in security operations, engineering, and development in other groups. At the same time, a lot of the roles have limited involvement in building of the threat model. Some of the roles are consulted or informed. This drastically reduces the amount of time and effort required for building an effective threat model while closing important informational gaps.

VerSprite’s RACI diagram is now made available for free on our GitHub page or directly from our website.

To learn more about the importance and implementation of threat modeling, click here.

VS-Labs:Security Research

We Solve Complex Technical Challenges VerSprite’s Research and Development division (a.k.a VS-Labs) is comprised of individuals who are passionate about diving into the internals of various technologies. Our clients rely on VerSprite’s unique offerings of zero-day vulnerability research and exploit development to protect their assets from various threat actors. From advanced technical security training to our research for hire B.O.S.S offering, we help organizations solve their most complex technical challenges.

The post A Look at RACI Models within Application Threat Modeling appeared first on Versprite.

Operationalizing CISA Alerts with Threat Models for Effective Cybersecurity

✇VerSprite
bigdrop

In this blog, we’ll exemplify how to leverage a threat advisory, revealing CVE alerts from Cybersecurity and Infrastructure Security Agency (CISA) and see how such alerts could be operationalized into an organizational threat model so that such alerts and helpful advisories can get contextually made relevant to an organizational threat model.

The recently published joint Cybersecurity Advisory (CSA) is focused around the top vulnerabilities and exposures exploited by Chinese state-sponsored threat actors, who continue to actively target US and allied organizations, software and hardware companies, stealing intellectual property and gaining access to sensitive networks.  This advisory reflects geopolitical and economic factors that often shape threat trends and must be taken into consideration when developing an organizational threat model.

An organizational threat model with relevant threat libraries containing unique threat assertions are always best when unraveling how relevant they may be to the attack surface, business operations, people, processes, and vendor relationships of a company.  In short – context and risk relevance.  These are ideal and the CSA advisory should be funneled into a process that examines whether such an advisory is contextually relevant to the organization.   This examines contextually relevant threats.  As an aside, this should not, however, discount generic threats that should still be considered as part of any threat model.  To further this brief tangential point, consider the following examples of universal threats that affect any organization:

– Cryptojacking an organization (making money by squatting on their infrastructure);
– Establishing persistence in an organization (to sell that persistence to other interested threat actors);
– Distributing malware (on target infrastructure);

Organizational threat models account for both unique and universal threats and both benefit from threat advisories (like the one shown above).  Advisories can be ingested into any organizational threat model and provide substantive evidence to attack patterns that may prove effective against an attack surface.  In the CISA advisory, we see affected technology components that are identified as being vulnerable. This vulnerability has to be associated with attacks that support a threat motive for each threat assertion in the threat model.  Important to know is that there are threat campaigns that are designed and launched with less targeted goals, resulting in more opportunistic hacks – these advisories, therefore, are good for universal or generic threats that may be a part of any threat model.

CISA Advisory

The advisory shown is really introducing two things – vulnerabilities being exploited as part of threat campaigns.  All this information is important to distill uniquely in order to reconcile vulnerabilities from these advisories to threat assertions developed within the threat model.  Important to differentiate vulnerability threat assertions from vulnerabilities that facilitate opportunistic attack patterns that support these and other generic, industry-agnostic threat patterns and threat motives while doing organizational threat modeling.

The key takeaways here are the following:

  1. Organizational threat models put everything into context.
  2. These threat advisories map to stage IV of PASTA and reconcile to generic threat assertions in a custom threat library within the model.
  3. Activities around attack surface management (Stage 2 of PASTA) now become correlated to these types of advisories.
  4. These advisories really come to life in stage v – vulnerability analysis of PASTA and get correlated to the threats in the threat model that are birthed in Stage 4 of PASTA.

Sharing the status quo on these and other advisories is to knee-jerk and ad hoc to see if one is affected. However, a more organized contextual approach is to funnel these activities into a risk-centric organizational threat model.

To learn more about threat modeling and PASTA methodology, click here.

PASTA Threat Modeling: The Process for Attack Simulation and Threat Analysis

VerSprite leverages our PASTA (Process for Attack Simulation and Threat Analysis) methodology to apply a risk-based approach to threat modeling. This methodology integrates business impact, inherent application risk, trust boundaries among application components, correlated threats, and attack patterns that exploit identified weaknesses from the threat modeling exercises.

The post Operationalizing CISA Alerts with Threat Models for Effective Cybersecurity appeared first on Versprite.

Risk-Centric Threat Models as Blueprints to Operationalizing Cybersecurity

✇VerSprite
bigdrop

Introduction: SOC Processes Are Flawed

Desensitization, as defined within the psychological definition, is a process that diminishes responsiveness to adverse events after repeated exposure.

As I write this near midnight, I can’t help but think of the hundreds of security analysts that work within the confines of security operations centers (SOCs) worldwide, perhaps on a second or third shift, eyeing alerts from log aggregators, security incident event monitoring (SIEM) solutions, or even event correlation engines.

That was me in 2005. Even now I remember the stamina needed to stay focused and engaged to the alerts that came into what seemed like a never-ending queue, much of them even labeled as false positives by fellow associates from prior shift notes or the event tracker itself. I wonder if the analysts today feel desensitized over their 8, 10, or even 12-hour shifts, as they receive security alerts from multiple infrastructures that they’ll never even know contextually what purposes they serve.

Of course, those analysts will become desensitized. Hackers count on it every day and have for years.

I make this point facetiously to draw some much-needed light to the status quo methods of running and subscribing to SOC services in 2020. As many continue to search for the silver bullet of products to correctly identify an indication of compromise based upon 20, 30, or even 50 distinct events for in-scope infrastructures, systems, and applications, I would like to point out many key observations that indicate today’s SOC processes are fundamentally flawed.

The observations are as follows:

  • The SIEM Alone SOC. Most of us in the field know of countless failed or incomplete SIEM implementations. If a SIEM alone is the primary tool shaping the security analysis of your SOC personnel, you may be missing a lot of valuable information. Regardless of the number of flows going into your SIEM, poor implementations and configurations may undermine the expected results of a solution that is traversing all log events as advertised.
  • Denial of Threat Information. Tools are ingesting massive amounts of information and often, the quality of how the information is ingested, parsed and then reflected back to analysts is not effective for triaging.
  • Many SOCs Use the Wrong Metrics. Many MSSPs are driven by metrics that make them appear that they are focused on service. Events mitigated, closed incidents, total alerts processed, and high risks addressed are just some of the examples of “wrong” metrics that fuel SOC today. These metrics are focused on demonstrating numbers in work that may not be useful or relevant for threat mitigation. Many of the events or incidents reflected as “closed” may not have been true positives and (most importantly) may not really pertain to an organization’s threat model.

Introducing Organizational Threat Models

Threat models serve as a pattern that allow organizations to more easily identify a list of threats against a target. In an organizational threat model, the organizations serve as that target.

The model itself is intended to mesh together a custom threat library [against a target], along with associated threat motives, probable attack patterns, vulnerabilities that facilitate threat objectives, associated targets, and a list of countermeasures that help resist the effectiveness of attack patterns that support threats and their objectives. Notice that the items in bold represent factors that contribute in the calculation of risk.

This is an important distinction because the messaging of what is attacking a target is important to understand, particularly for those that are on the front lines of monitoring adverse alerts on a target’s infrastructure.

The organizational threat model essentially provides a way for context to find its way into the role of security operations. Beyond simply relying on tools to govern decisions, an organizational threat model provides the context that security analysts need to think about what is important based upon the likelihood, severity, and accuracy of both threat data and threat intel.

Organizational Threat Models as a Blueprint for Threat Intelligence

At this point, organizational threat models are not something that snap on as a plugin to a SIEM or threat intel subscription feed, but something that can be instead used to train SOC analysts on how to think in the trenches when triaging security events and incidents.

The organizational model will allow a team of SOC analysts to ask the following important questions:

1. Who is my enemy?

  1. Understanding motives and likely threat actors is important because the majority of cybercrime is a copy, or rehash, of prior successful attacks. The current gap today is that most analysts do not actually know or understand who their attacker is and are forced to play detective on purely aggregated log information/threat intel, which doesn’t bring a lot of context. It’s important that a threat actor profile be developed so that, with an understanding of a company’s exposure, analysts can correlate to see if abuse patterns to company infrastructure, assets, and applications match threat motives that pertain to a threat actor profile.
  2. The answer to this question is determined largely from threat intelligence feeds, advisories, industries CERT/ ISAC reports, and more. It allows for the analyst to match a developed threat actor profile to threat events worldwide that may be targeting the industry of a specific target(s).

2. What are they after?

  1. Profiling an enemy naturally leads to answering the question of what this enemy wants. Many inexperienced security analysts may just be focused on data-based attack patterns, meaning attack patterns that are simply looking to exploit and pilfer data sources. Not all threat actors are looking for data; some may be looking for persistence and others may simply be looking to burn the whole place down.
  2. Understanding what targets are in-scope based on trends, prior incidents, other threat advisories and intel is how these types of information can go from simply mass consumption of threat information that looks like noise to more selective filtering that leads to improved analysis. Knowing what to protect is a fundamental part of defense and it’s not fulfilled with simply a point-in-time discovery. Discovery of what is in-scope for monitoring and defense is an ongoing process that can be automated for virtual, physical, data, and application assets.

3. What trends have developed or are forming?

  1. Trends have lifecycles. Many companies react to trends at different stages and today, there are virtually no SOC analysts that are thinking about trends. In the “trenches”, trend discussion is important because it makes the discussion more fluid in the minds of the analysts. Some companies may argue that trends are looked at via feeds or at higher management levels. Unfortunately, at this level conversations don’t become operationalized, which is why it’s important to allow for analysts to not only have news run within their operational centers but to allow them to converse on what trends may be forming in real-time or may already have formed and to discuss how this affects their fluid threat model.
  2. It’s also important to note where trends come from, as there are many different types of trends. In threat analysis, you have economic trends as you do have trends in social engineering attack vectors. Often, the latter serve as obvious trends and are presented to analysts after the point that they are able to take a proactive stance. Security trends are largely based upon inquiries with analysts, surveys, annual reports, or other sources that assess market conditions. This means the activities that shape these trends have been occurring or are currently occurring, thereby forcing company operations centers to react versus foresee possible threats. The improvements of correlation engines to collate similar events on a corporate network does allow companies to start thinking more proactively, and this should be greatly encouraged within the trenches.

Building and Operationalizing a Threat Model for Defense

Organizational threat models can leverage a framework like the Process for Attack Simulation and Threat Analysis, or PASTA, to think about building a threat model in both an offensive and risk-based perspective. The idea of a risk-centric approach like PASTA is that it compels a threat modeling security champion to focus on the things that matter, where what “matters” are things that support the business in a way that is of critical or high importance. It leverages elements of a business impact analysis in order to help qualify the criticality of components that support an organization.

The simple steps to building a threat model using PASTA is to leverage the activities that are depicted in every stage of the threat modeling methodology. These stages are simplified below with a lite version of some exemplary artifacts, questions to ask and objectives to achieve. It is by no means comprehensive, but they do help to convey the idea of each stage number. It also correlates with sample tech genres to help depict how this can all come together for a threat-focused Security Operations team.

Threat Modeling Methodology Stages

Conclusion

Over the years, VerSprite has found threat models to provide an excellent lens through which our threat intelligence group supports various clients. With a unique client profile and threat model in place, alerts can become a lot more contextualized, which allows us to truly be analysts versus simply looking at their roles as tool administrators or ticket managers for security tickets in a queue. I hope this write-up encourages others to consider threat models in their own respective SOCs for improved analysis and response by their blue teams.

PASTA Threat Modeling: The Process for Attack Simulation and Threat Analysis

VerSprite leverages our PASTA (Process for Attack Simulation and Threat Analysis) methodology to apply a risk-based approach to threat modeling. This methodology integrates business impact, inherent application risk, trust boundaries among application components, correlated threats, and attack patterns that exploit identified weaknesses from the threat modeling exercises.

The post Risk-Centric Threat Models as Blueprints to Operationalizing Cybersecurity appeared first on Versprite.

Penetration Testing Methodology: Emulating Realistic Attacks by a Malicious Actor

✇VerSprite
bigdrop

Penetration Testing Methodology

The foundation of VerSprite’s penetration testing methodology is based on emulating realistic cyber-attacks by a malicious actor through the use of a threat modeling methodology PASTA (Process for Attack Simulation and Threat Analysis).

PASTA consists of a seven-stage process for simulating attacks and analyzing threats to the organization and application in scope with the objective of minimizing risk and associated impact to the business.

VerSprite Penetration testing incorporates the methodology and aims at solving the probability variable in a risk analysis of realistic attack patterns. Targeting exposed corporate network endpoints, hosted infrastructure, supporting platforms, or pivoting off third-party solutions – pen testing emulates current and advanced attack patterns in both black box and gray box scenarios.

VerSprite’s OffSec team also supports the following global standards as a part of Application Security testing:

Penetration Testing Methodology
 

Application Threat Modeling

This risk-based threat modeling approach goes beyond traditional threat modeling by enabling a company to make security decisions driven by business objectives.

This posture to both application and network security that VerSprite takes by assessing the operational impact and the threats to the business before evaluating the security of the applications, services, and infrastructure in scope helps not only to understand the vulnerabilities but remediate them in a business rationalized manner.

Thus, each penetration test exercise begins by modeling the threat to understand attacker motivation and possible targets. Then, we identify likely attacks that can cross technologies, people, and processes, and assess the strength of the countermeasures to resist attacks. This allows for decisions on mitigation of vulnerabilities to be made based on the operational risk to the business.

As a result of this very first phase for every engagement, VerSprite will have acquired at least the following information to then walk through the corresponding methodology, selected based on the type of engagement:

  • Business objectives for the application/service/infrastructure in scope;
  • Business use cases that are the most critical/sensitive;
  • Abuse cases that are the most critical/sensitive for the business;
  • Possible Threat Actors targeting the application/service/infrastructure in scope;
  • Principal Threat Motives;
  • Type of targeted information and assets in scope;

This approach allows VerSprite to understand security from both a business and attacker perspective in order to model and simulate realistic attacks during the engagement, pressure test the security posture being targeted, and provide key insights and recommendations that align security with business.

VerSprite’s methodology during client engagements is commensurate to the type of security effort that is provided and the objectives for the exercise.  As seasoned security professionals, the team recognizes the effectiveness of industry frameworks and standards that exist across an array of security disciplines, but at the same time understands that there are no one-size-fits-all solutions.

As a result, VerSprite successfully employs the use of both in-house developed, as well as renowned and well-regarded methodologies as part of the consulting engagements in order to align the client deliverables and security services to an industry acceptable level of security management.

Applying PASTA to Penetration Testing

The use of PASTA and VerSprite’s Threat Modeling methodology will guide the ensuing penetration test exercise, which can be performed in different ways depending on the approach to take and how much information is to be shared during the testing. The best way to see this is as follows:

  • Blackbox Application Penetration Testing takes a DAST (Dynamic Application Security Testing) approach and assumes no prior information is provided about the target. With this type of approach, VerSprite’s team of experts attempts to simulate an attack by a threat actor that would have little to no insight into the environment or application architecture.
  • Whitebox Application Penetration Testing takes a SAST (Static Application Security Testing) approach where the source code of the application is provided for its review. Depending on the size of the application, this can be time-consuming, but if performed along with an application threat model, this could be the way to go if you are looking to find as many issues as possible and understand if secure development best practices are being followed. If a test environment is available during the exercise, every finding can be validated dynamically to provide a better Proof of Concept that shows the real impact of exploiting the vulnerability
  • Greybox Application Penetration Testing takes a DAST approach, and credentials are provided to perform authenticated testing. Additional documentation can be shared around the environment and architecture of the application to help in understanding its inner working and how the different components work together. If the source code of the application is also provided in order to support the testing, the Application Pentest takes a mixed approach between dynamic and static analysis instead. This Greybox approach allows for combining the convenience of DAST with the depth of analysis provided by SAST, which not only saves time during dynamic testing but also enables the possibility of going deeper in the review of critical functions to the business.

Regardless of the type of engagement, VerSprite takes a completely manual approach to testing; automated testing is only an option for a breadth of coverage or when necessary to complement certain tests.

This guarantees a more in-depth understanding of the target which, in the end, provides better quality results in terms of findings while eliminating false positives and providing real Proof of Concepts for each of the issues found. Interested in learning more? Contact us here.

Shift Towards a Better & More Modern Cybersecurity

VerSprite provides enterprises with results to support their security efforts, meet business objectives, and provide stakeholders and decision-makers with solutions and guidance to scale the business.

The post Penetration Testing Methodology: Emulating Realistic Attacks by a Malicious Actor appeared first on Versprite.

VerSprite Partners with Stellar Cyber, Cybereason, & D3 Security to Streamline and Automate Virtual SOC Services

✇VerSprite
bigdrop

Summary:

  • Why Virtual SOC?
  • Operations Center Future – from complexity and overload to automation and intelligent operations.
  • VerSprite vSOC Full Stack – the people and technology behind the most effective enterprise security.
  • VerSprite Virtual SOC – effective automation and real-time monitoring.

Geopolitical tensions, economic uncertainties, expanding enterprise network surfaces due to cloud environments, IoTs, and remote workers. These are some of the major factors, that create a perfect storm for threat actors to thrive, seeking out vulnerabilities and weaknesses in networks, and exploiting the slow pace at which organizations are adapting to the rapidly evolving cyber landscape. While companies act on “first expand, then implement security measures” tactic, the threat actors are ready to take advantage of the gap. Add COVID lockdowns, Russian war, tensions with China to these hybrid environments, which drastically changed the cyberthreat landscape, and a traditional security operations center simply cannot keep up, no matter how many new stand-alone tools are employed to help the SOC personnel. More tools, lack of correlation, alert fatigue only create more security gaps and opportunities for criminals. Current models for cybersecurity are insufficient and broken.

VSOC provides the security monitoring, response management, and analysis of the networks, while reducing not only cyber risks, but the cost of operating a traditional SOC. Outsourcing the center to professionals makes securing your organization possible at a fraction of time investment and cost of an in-house SOC.

VerSprite introduced the Virtual Security Operations Center services as we recognized the growing need for effective cybersecurity management. VerSprite vSOC has real-time response capabilities, automation and AI driven solutions. It is operated 24/7 by a skilled cybersecurity expert team. Our security center is a complete tech stack that provides expert analysts, top industry tools integrated into the security processes, custom threat intelligence, and even compliance screening.

Introducing VerSprite Virtual SOC Full Tech Stack:

Top Experts – Leading Industry Security Tools (Cybereason, Stellar Cyber, and D3 Security) – 24/7 Operation

We believe that technology is only as good as the people who operate it. We hire top talent, who undergoes continuous training to stay up-to-date with the ever-evolving cyber threat trends and technology. Our expert team works around the clock to monitor and respond to potential breaches and threats.

Over the years, VerSprite developed many internal security tools and methods, as well as continuously testing new technology to find the best tools to ensure the best possible protection and the most effective vSOC operations.

VerSprite developed a correlated process for the security operations center, that monitors endpoints and data across the entire enterprise and provides instant response and remediation guidance. After an extensive research and testing, we have partnered up with industry’s leading cybersecurity providers.

Our full-scope vSOC offering provides EPP (endpoint protection platform) and EDR (endpoint detection and response) developed by Cybereason. It delivers policies, management, and security controls that guard endpoints. Cybereason is operation centric and focused on delivering future-ready attack protection to outpace and stop even the most sophisticated attacks on the endpoint and beyond.

Cybereason platform collects the data and actions of users and communicates the information to the Security Information and Event Management (SIEM). VerSprite works with Stellar Cyber SIEM, an industry-leading security software and the only security operations platform that provides high-speed, high-fidelity threat detection and automated response across the entire attack surfaces. It helps eliminate the data overload and improves security operations productivity while reducing the response time from weeks to days. Stellar Cyber SIEM collects the telemetry and automatically correlates it with other data sources, cloud logs, active directories to give a better picture of an event tied to a user’s action, such as engaging with a phishing email. VerSprite’s experts utilize the D3 Security  next-generation SOAR platform, that allows the security team to rapidly identify and resolve advanced threats. It receives and analyzes the data from the SIEM, then automatically takes an action to alert the team and mitigate the possible risks. The D3 SOAR platform collects data from a variety of sources and then orchestrates tailored responses using playbooks that combine security tool integrations, automated workflows, and human input.

VSOC

Partnerships with these top security platforms and the highly-trained experts allowed our Virtual SOC to provide the automation and efficiency that meets the demands of the current cyberthreat landscape. VerSprite’s refined VSOC, whether fully-employed or an extension to an organization’s in-house SOC, ensures insight, coverage, and timely protection across the entire enterprise network, while reducing cost and eliminating the complexity.

Evin Hernandez, VerSprite VP of Product, explains the benefits of the VerSprite virtual SOC:

“By using our virtual SOC, we can prioritize security events by focusing on the incidents that have the most impact to your business, using the latest threat intelligence to prioritize, respond, and remediate these events. In an on-premise model, it would be up to each security analyst to communicate with other analysts to determine whether each tool’s individual detection, while possibly looking benign, can correlate with other detections from other tools to reveal a complex attack. This is all taken care of by VerSprite’s virtual SOC security experts.”

Virtual SOC reduces risks and enhances security and effectiveness, which translates into higher ROI while scaling the business securely. It saves companies 50-75% by dispelling startup cost, such as procuring proper tools, reducing the time it takes to become operational, and eliminating the ongoing management expenditure (hiring and training staff, managing multiple product licenses). Employing a virtual SOC allows enterprises to make a shift from the complexity of sustaining an in-house security center to the efficient intelligent cybersecurity management and real-time monitoring.

For more information on how VerSprite can help consolidate your organization’s security efforts, contact us.

Shift Towards a Better & More Modern Cybersecurity

VerSprite provides enterprises with results to support their security efforts, meet business objectives, and provide stakeholders and decision-makers with solutions and guidance to scale the business.

The post VerSprite Partners with Stellar Cyber, Cybereason, & D3 Security to Streamline and Automate Virtual SOC Services appeared first on Versprite.

Cybersecurity and Physical Attacks Against Your Business

✇VerSprite
bigdrop

Physical Security Attacks Are Easier Than You Think

What happens once a threat actor has physical access to an information system or any other item of interest? Your first thought may be that all is lost. That the game is over. This mindset is wrong.

Any random passerby on the street has physical access to the car you left parked in the parking lot, but that should not mean you should expect any of them to start it and drive away effortlessly. Any modern vehicle will put up defenses that increase the costs for nearly all attackers to keep your car where you left it. We expect physical security of our phones as well, assuming we encrypt the phone and secure it with strong passphrase and biometrics.

Any modern organization should have physical security sufficient to quickly discourage nearly every possible attack and enable efficient detection of active attacks. However, as quite often the case, during Red Team Assessments, we find that physical security stops at the front door:

  • Workstations are not encrypted.
  • Network ports are not locked down.
  • Flash drives containing sensitive data are placed in unlocked drawers.
  • Printouts of customer and client data are piled on desks.
  • Electronic equipment and confidential documents are placed behind doors with insecure locking mechanisms.
  • The primary backup server is in the same building and even the same room as the original data.

Security requires a layered approach, known in the industry as “defense in depth.” Stakeholders should place proper emphasis on secure software development practices, hardening system configurations, and tightening firewall rules. However, the physical security of the very things we are trying to protect often goes overlooked. Next-generation-machine-learning-in-a-box with bright blinky lights means little if the doors protecting networking equipment or a room full of blank checks and customer data can be opened with a smile at reception and hotel key card. Most organizations have some level of physical security in place. Still, you will never know how effective your securities are until they have been stress-tested to see if the elements that make it up – like locks, cameras, and policies – can handle the scrutiny of a simulated physical attack.

Is Your Organization Prepared to Respond to a Physical Attack Incident?

Real-Life Red Teaming Example Shows It May Not Be.

Incident response plans may be developed out of theory in a meeting room but never stressed. In a real-life stress-test conducted by VerSprite, a client hired us for a red team engagement. In the day following an after-hours break-in we oversaw, a security team member spotted us on their cameras and performed an investigation into what we may have done within their offices. As it turns out, their incident response procedures had serious gaps we exploited to allow a rogue device we planted to go undetected for the duration of the engagement after our break-in was discovered.

This story, along with other real-life red teaming findings, are presented below.

Exposing Gaps in Post-Breach Investigations

Let’s go back to the case of the client we just mentioned, the one where we managed to gain physical access to their office during after-hours on a red teaming engagement. Unfortunately for us, and fortunately for our client, someone happened to review the CCTV footage.

To pass compliance, the client had to have a certain number of CCTV cameras in specific locations. One CCTV camera was facing the network closet where they stored laptops and networking gear, but they were not required to have a camera in the closet, so there was no camera inside.

The CCTV footage of our physical breach was reviewed, and the client’s security personnel noticed we spent a lot of time rifling through drawers, capturing photos, and gaining access to the network closet by sliding a hotel key card between the strike plate and latch. The individuals reviewing the CCTV footage, unaware of the red team exercises, understandably thought it was odd that we spent so much in that room. What they found on camera was that we walked out with one of the company’s laptops.

In a post-breach debrief with the client, we found out they thought the only thing we took was a laptop. They searched the network closet to see if we did anything else and could not find anything. What did we do in the network closet? We planted a rogue device that gave us access to their internal corporate network. A single misplaced cable, installed by us to connect our rogue device to their network, was hanging out of the rack. We left this cable as a clue, but as it turns out, that cable went overlooked during their investigation.

Due to this oversight, our team had access to their internal network for several weeks, uncovering a wide variety of insecure Jenkins deployments, AWS keys on open network shares, and weak credentials leading directly to customer PII corporate banking details. While the findings in the internal network are concerning, what is equally disturbing is how easily we gained access to the networking racks using nothing more than a hotel key card. While we broke in at night, any employee or member of the cleaning crew could have done the same thing and likely have never been caught.

The client learned the importance of formalizing and thoroughly testing incident response plans to ensure the aftereffects of a breach are thoroughly addressed and managed as part of an exhaustive investigation. In addition, we helped them realize the inadequacy of their door locks and camera placement.

Physical Attackers Use Tailgating, Badge Cloning, and Even Dust for Fingerprints on Keypads

In nearly every physical security assessment, we find a way to break in. In one engagement, the building our client occupied had security guards on staff 24/7. The client had a small office in the building, and the objectives were to gain access to the office, gain access to sensitive data on workstations, and plant a rogue device. During the day with employees in the small office, planting the device would be difficult, so we decided to perform the attack after-hours.

We tailgated employees to gain access to the building during the day, and then we walked around long enough for our badge cloner to clone badges. The cloned badges allowed us to enter the building not only during business hours but also after-hours. Unfortunately, while we could enter the building, the elevators were locked and would require an override by building security. Dealing with building security after-hours was risky, so we looked for alternatives. We did some online research and managed to find a detailed map of the building. We planned a route that would bypass the security desk and security cameras, leading us through a maze of hallways to a set of stairs that were unlocked. We managed to walk up ten flights of stairs to get to our client’s office door without being stopped or questioned.

At the client’s office door, we saw a keypad:

By taking photos at various angles, studying the marks, and noticing the food particles and dead skin cells jammed in the crevasses between buttons and the plastic panel, we could generate a list of possible numbers for a PIN. In this case, we figured that 2, 3, 5, 8, 9, and 0 were likely candidates. We generated all possible 4-digit combinations of these digits and compared this to public research on the probability of a given 4-digit PIN code being used. Taking from the top candidates, we found a code to unlock the door!

Once inside the office, we identified several concerning things about the office’s state of physical security. Aside from the usual array of clean-desk policy violations and insecure Request-To-Exit (REX) door sensors, we found other things that are typically overlooked.

One issue was that USB ports were not disabled on the workstations, despite a policy about employees not being permitted to use USB devices. To exploit this, we used the BashBunney in combination with the QuickCreds script to trick Windows into installing a fake Ethernet adapter and performing NTLM authentication with our device, allowing us to obtain hashes that we could later crack to login to the workstations.

In cases where we could not crack the hashes to log in to a workstation, we were able to boot to a Live Kali operating system on a flash drive. This led us to realize the storage drives were not encrypted with BitLocker or any other full-disk encryption solution. So, booting to a Kali Live OS allowed us another way to gain access to business-critical data and place backdoors on the workstations.

After continuing our search, we found that the computer responsible for mainlining physical access controls to the office, namely the HID card reader and keypad we saw out front, was in the break room. To make matters worse, this computer had no password for the administrative user. Hence, we could play the part of a malicious employee or unscrupulous visitor and copy all the existing PIN codes or even create our own. (We didn’t, of course, but the next person may not be as gracious!)

What Can You Learn from This Red Team Assessment?

Red teaming assessments should allow your organization to identify systemic issues rather than finding just one way and calling it quits. In a real-world situation, a malicious infiltrator won’t stop after the first try. So, we always try different approaches to highlight systemic problems. It is not enough to say, “we broke in once, and here is how we did it.” Given all the different attack motives, it is essential to show all the different ways anyone could compromise an organization and highlight all the systemic issues missed by everyone else. So, it is with that we move on placing a rogue device on their network.

Weak Wireless Security Can Lead to Physical Breaches

On one red team engagement, we found that the client had a forgotten wireless network that was “secured” with Wired Equivalent Privacy, or WEP. WEP is a predecessor to WPA wireless security and is considered severely broken. Any WEP password can be cracked in a matter of seconds, regardless of complexity.

In debriefing with the client, it was revealed that the wireless network was supposed to be taken down a long time ago. Still, the ticket got lost, staff changed, anyone that would have remembered it did not work there any longer, and it has been years since an inventory was done of wireless networks.

Within a few minutes of arriving on-site – while sitting in our car in the parking lot – we found this wireless network and cracked the password in seconds.

We connected to the WEP network, scanned their internal network, and discovered a Honeywell NetAXS keycard security system:

We were able to log in through brute-force to view live security camera feeds from inside their office:

Further, we found that the web interface allowed us to disable the magnet locks on the doors manually. This allowed us to come back during after-hours to unlock the doors and have free reign of their offices. We use that after-hours access to plant voice recorders, locate business-critical data on their computers, and ultimately gained access to propriety source code by tapping into their network equipment.

The lesson here is clear and outlined very well in the 20 CIS Controls: continuously inventory hardware assets and software assets and ensure that assets are securely configured. If you do not know what you have, you will not know where your vulnerabilities can be.

Conclusion

Of course, you can try to find these security gaps yourself, but first – recall the quote we mentioned in the first blog post in this series:

“One thing a person cannot do, no matter how rigorous his analysis or heroic his imagination, is to draw up a list of things that would never occur to him.”
– Thomas Schelling, Nobel Laureate

Here is where creative thinking from an unbiased outsider, that cultivates the hacker mindset, comes into play. A partner like this can see angles missed by others to expose overlooked weaknesses. Otherwise, you may knock one issue off the checklist while unintentionally leaving several other problems overlooked. These issues will only be spotted by unbiased, trained eyes, like those of myself and those on our Red Team, that has an innate interest in breaking past barriers, showing organization how it can be done, and offering a hand in helping you grow past them.

How Can You Test Your Physical and Cyber Security Controls?

In this last iteration of this series, security expert, James Sibley, broke down how Versprite’s Red Team used physical security weaknesses to gain access into organizations. Follow the links below to read about other examples of cybersecurity weaknesses uncovered by VerSprite’s team in real-life:

Put Your Physical and Cyber Security To The Test

VerSprite’s Offensive Security team focuses on emulating cybercrime and simulating test scenarios that reflect real-life attack patterns, taking in consideration threat actor’s motives and business objectives. Our team can perform risk-based penetration testing, vulnerability assessments, red teaming exercises, and custom organizational threat models to expose your security gaps before your attackers do. Learn More→

The post Cybersecurity and Physical Attacks Against Your Business appeared first on Versprite.

Threat Modeling Within Software Development Lifecycle

✇VerSprite
bigdrop

Building security in the SDLC – a time and cost-efficient security solution beyond a simple application validation requirement

Software is the backbone of every application. Application performance and longevity is dependent on how well software is built, as well as how secure it is. Historically, security in the software has been mostly considered a requirement to be validated with functional testing during the last phase of the SDLC. However, the software development lifecycle is a complex process, that encompasses different phases such as software functional requirements, software design, coding, building the software to an executable, integration with other software libraries, and building to create an executable, functional, quality testing.

Implementation of fixes for the issues identified at the final stage of testing requires time and resources. Building in risk-centric security from the inception of the software is a cost-effective proactive approach to creating secure software and application.

The process, often referred to as secure software engineering, allows for embedding software security activities during the different phases of the software development lifecycle, such as requirements documentation, architecture design, coding integration with other libraries, and building the execution and testing. Implementing secure activities throughout the SDLC builds a more secure software foundation and makes sure that cybersecurity culture is woven into the development process. It also allows you to identify and rate vulnerabilities according to their technical risks and remediate them accordingly in the process. It eliminates issues with backtracking to implement fixes, failing testing, and not meeting requirements.

Proactively securing the application in the SDLC is an offensive approach to security, which presents fewer opportunities to threat actors to exploit vulnerabilities, and the organization has the least risk of these being exploited.

 Importance of embedding threat modeling into SDLC

Identifying security issues in software prior to these issues being exposed into the production environment is an important factor for mitigating the possibility and the impact of the cybercriminals targeting these vulnerabilities.

Steps to secure an application with threat modeling (PASTA):

  1. Identify the potential threats and threat actors to the application.
  2. Identify the functions of the application and its objectives.
  3. Analyze the assets that can be targeted by cybercriminals
  4. Determine the type of attacks and attack vectors that can be used and the type of vulnerabilities that can be exploited by these vectors
  5. Set the security measures that can be put in place to mitigate the risks

The main goal of embedding threat modeling is to identify potential risks as early as possible, so that they can be managed by designing, implementing, and testing countermeasures throughout the SDLC.

Advantages of Embedding Threat Modeling in all the Phases of the SDLC are:

  1. Risk management. It allows risks to be managed proactively from the early stages of SDLC.
  2. Security requirements. Deriving the security requirements to mitigate potential risks of vulnerability exploits and targeted attacks against application components.
  3. Secure design. Ability to identify security design flaws, their exposure to threat actors and attacks, and prioritize fixing them by issuing new design documentation prior to the next phase of the SDLC.
  4. Security issue prioritization. Determining the risk exposure and impact of threats targeting issues identified during secure code reviews and prioritizing them for mitigation.
  5. Security testing. Deriving security tests from use and abuse cases of the application for testing of the effectiveness of security measures in mitigating threats and attacks targeting the application.
  6. Secure release of applications after development. Allowing business to make informed risk decisions prior to releasing the application based on the mitigation of high-risk vulnerabilities and assertion of testing countermeasures that mitigate specific threats.
  7. Secure release of application after an incident. Determining and identifying additional countermeasures that can be deployed.

Designing for security and for attack resilience: secure architecture, training and awareness, security assessments and testing

Threat modeling within the SDLC builds attack resilience. It helps identify potential threats and attack vectors that can be used against the security controls, which allows to proactively design countermeasures to protect them.

At the architectural level, a threat modeling exercise can include the threat analysis of these threats and attack vectors as well as the analysis of the architectural components that can be attacked, such as user interfaces, databases, and server components, which include web and application servers and the data flows between them.

By following step-by-step application threat modeling methodology (PASTA), it is possible to analyze the exposure of application components to different threats and determine the type of measures that can be deployed at different architecture levels to mitigate such threats.

The assessment of the secure architecture of an application also represents an opportunity to design applications that are complaint with the organization’s infosec requirements to protect sensitive data in storage and in transit, as well as implementing necessary access controls. It also ensures government regulations compliance.

Additional benefits of the application threat modeling integrated as a part of SDLC:

  1. Threat modeling bridges a gap between information security and engineering teams. It gives an opportunity to educate engineering teams about application security standards, security architecture, and vulnerabilities, as well as security risks and countermeasures to take into account.
  2. Threat modeling is used to communicate technical risks to application development stakeholders, so they can make informed risk management decisions and prioritize mitigation efforts toward the vulnerabilities with a highest risk values.
  3. Threat model helps determine the possible exposure of vulnerabilities which allows for visualization of data flow. Threat model can be used in secure code review to determine whether the issues identified in the software components might be exposed to the potential internal or external attack vectors.
  4. Security testing also benefits from threat modeling embedded into the SDLC. For example, penetration testing runs a suite of common attack vectors against the application. Performed during the development lifecycle, it can identify exploitable design flaws in time to prevent costly repair and time loss, as well as ensure proper security controls are implemented.

Integrating Threat Modeling within the Different Types of SDLCs

 

“When to use iterative development? Only on projects you want to succeed.”

Martin Fowler, UML Distilled.

Here we take a closer look at the implementation and benefits of the threat modeling in different types of Software Development Lifecycle: waterfall, interactive, agile, and security enhanced.

Threat Modeling and Waterfall SDLC

Software can be developed using different types of SDLCs. Waterfall SDLC is a traditional linear software engineering process that follows each of the phases sequentially, starting from the initial requirements phase, following through the design phase, the coding phase, and the final testing phase.

This type of software development is one of the best suited for integration of security activities such as threat modeling.

Breakdown of benefits of the threat modeling by phase:

  • Requirement phase. At the beginning stage, threat model identifies threats against the functional use cases of the application by considering a threat agent, such as an attacker trying to abuse the application functionality. It then derives a set of abuse cases that map to each of the use cases with an abuse functionality. This help to identify security requirements to mitigate the risks to the application.
  • During the design phase, threat modeling identifies specific threats against the components of the architecture, such as the user interfaces, the data processes, the data flows, and the data in storage. At this stage, threat modeling reveals security gaps in the design of the security controls, as well as design weaknesses.
  • In the coding phase of the software development threat modeling determines the risk of the security issues identified in the source code after either a manual source code analysis or an automatic source code static test for vulnerabilities.
  • Testing phase prior to production. Threat model derives a suit of security tests that can be executed against the application to identify the potential security issues. This way, countermeasures can be redesigned and reimplemented before the application is released into production.

Threat model, embedded into the SDLC, is also beneficial after the application is deployed in the operational environment, as it helps to maintain security during subsequent releases and before change management events. Threat model can reassess potential new threats and security risks, allowing stakeholders to make informed decisions whether to implement the changes or determine new countermeasures.

Threat Modeling and Interactive SDLCs.

An example of an interactive SDLC is the Rational Unified Process (RUP). RUP is an extensible software development process that consists of four sequential phases (inception, elaboration, construction, and transition) and disciplines that are used throughout the phases (requirements, analysis and design, implementation, testing, deployment, configuration, and change management). RUP differs from a waterfall process in that each phase encompasses several iterations of a complete development cycle.

Security objectives, included in each phase of RUP through threat modeling, can be validated at each RUP milestone and used as a security checkpoint during the iterative development of the application.

Threat modeling within Interactive SDLD by phase:

  • In the inception phase, time and cost of the threat modeling is estimated and incorporated into the scope of the projects, business and functional requirements.
  • Architecture of the application is defined during the elaboration phase. This is where the bulk of the requirements is elaborated and threat modeling helps provide security requirements, based on the abuse cases. Through threat modeling exercises the security controls are also validated and designed to mitigate the risks of specific threats.
  • During the construction phase of the RUP SDLC the application software is developed. Here, the source code is reviewed for any vulnerabilities, using the results of threat modeling exercises, such as the identification of security design flaws in the application architecture.
  • The application moves from the development environment to production during the transition phase. From security perspective, the focus of this phase is to validate with security tests that the security controls of the application function as required and are acceptable for deployment as well as that the application does not include any known high-risk security issues that prevent release into the production environment.

Threat Modeling and the Agile SDLC

With the Agile software development methodology, applications are developed by refining the application requirements, design, implementation, and testing phases through different iterations until the final application is ready to be released into the production. These phases, also referred to as “sprints,” are executed more than once at subsequent iterations. Since each sprint represents incomplete design, it poses challenges to the threat modeling as it lacks security checkpoint enforcement and does not have a complete scope for assessment.

Due to these constraints, integrating threat modeling into the Agile SDLC may not be as effective as secure architecture design reviews integrated as a part of the Waterfall SDLC to identify security flaws in the design before starting implementation.

Nonetheless, certain threat modeling activities can be integrated into the Agile SDLC:

  • Agile stories, actionable statements describing a piece of business functionality, can be integrated with a threat modeling activity to identify threat scenarios and derive security stories. They will in turn define the security conditions for validation with security tests. The validation of security stories can be a part of the system integration tests as a part of the final application security acceptance review before releasing the application in production.
  • The security stories introduced ahead of each sprint can drive the documentation of the security requirements as well as secure design prior to each sprint.
  • Application security assurance review, performed between system testing and the release phases, provides an opportunity to drive threat analysis to make sure there are no vulnerabilities that can be exploited by known threats identified at the initial threat modeling.
  • Security tests can be integrated with the system tests to validate that the software functions as intended and is free of vulnerabilities.

Threat Modeling and Security Enhanced SDLCs

Security Enhanced SDLC is a software development process that incorporates security activities to enhance the security of the application by design, development, and deployment.

Microsoft Software Development Lifecycle (MS SDL) is one of the examples of the security enhanced SDLC. Its aim is to minimize the security-related vulnerabilities in the design, code, and documentation and to detect and eliminate vulnerabilities as early as possible in the development lifecycle.

MS SDL incorporates threat modeling and mitigation as some of the Secure by Design guiding principles, that include Secure architecture, design, and structure, Elimination of vulnerabilities, and Improvements in security.

SDLC

Software security is complex and paramount to the continuity of the application and, at times, business. Threat actors always look to exploit weaknesses found within the structure of the software. Vulnerabilities that were introduced in the development stages can undermine entire business operations. Security must have a multifaceted approach that goes beyond mitigating risks discovered after production, or worse – having cybercriminals discover them. Introducing threat modeling at early stages of software development is not simply an offensive cybersecurity approach that effectively saves time and resources, it helps build stronger application foundation which work for business continuity.

To learn more about integrating threat modeling (and PASTA methodology) as a part of your business plan, contact us.

 

 

The post Threat Modeling Within Software Development Lifecycle appeared first on Versprite.

Security Awareness Training VS Social Engineering Techniques

✇VerSprite
bigdrop

Standard Security Awareness Training Does Not Protect Against Social Engineering Attacks. Here’s why.

Beyond external network attacks, companies should look into security blind spots surrounding their employees. Employees rely on companies to train them to identify malicious activity. However, most security awareness training does not account for the creative social engineering tactics hackers use to take advantage of an organization’s human weaknesses. For example, it is common to tell employees not to open email attachments from unknown sources. However, what if it is a part of an employee’s job to receive and open third-party attachments? Alternatively, what if the email came from a trusted source, but the employee was unaware the trusted source was compromised and sent malicious links?

In cases like these and many others, the fault is not the security awareness training but that most security awareness programs do not account for detection of blind spots. VerSprite’s consultants often manage to compromise trusted communication mediums during red teaming operations, including Slack accounts and employee email accounts. We used these critical communication mediums to move throughout the organization, compromising one account after another until reaching the engagement’s end goals, which are pre-defined between the clients, in collaboration with the offensive security team. These goals often focus on determining the ease in which attackers gain illicit access to business-critical data or business-critical systems.

Our red team rarely gets caught with this tactic. It is not until after reviewing exercise reports that clients realize they need visibility into more than just flagging emails from external sources.
This article highlights a sample of social engineering techniques VerSprite’s Offensive Security team (OffSec) has successfully conducted during red team exercises. These techniques focused on the human element of an organization to demonstrate how cybercriminals use creative ways to find and extort human error.

Using Phishing to Hijack Company Social Media Accounts

There are a few things that cast a light on the importance of operational security and overall security hygiene for a client; one is learning that they inadvertently left their corporate social media accounts open for hijacking. Leaving social media accounts unprotected can have detrimental effects on organizations, no matter the company size or amount of followers. The attacker has the power to post damaging content that can tarnish the company’s reputation and impact its bottom line.

For example, in a recent red team engagement, our client was Twitter verified and had over 18,000 followers, which added leverage to the company’s online presence. Verified Twitter accounts with a captive audience of thousands are valuable for attackers. Organizations often assume their social media accounts are secure because 1) they have not been hacked before and 2) that social media companies are looking out for their security. Believing (1) to be true does not make it true, and (2) is only true up to the infrastructure boundaries of the social media companies, leaving much of the reasonability in the hands of the account owners. Knowing this, organizations with large social media followings must ask themselves “how difficult would it be to hijack an account like this?” With a bit of technical know-how, creativity, and social engineering, it’s entirely possible.

To begin, we first had to identify the email address associated with the company’s social media account. For many Twitter accounts, this is not as difficult as it may seem. By initiating a password reset, Twitter will ask you for recovery options depending on your account settings. For our client, they allowed email. Twitter attempts to respect its users’ privacy by masking the email address, as seen in the screenshot below.

However, Twitter does not mask the length of the email address. Given that we knew the client’s name and website domain name, we were confident this was a company email address by matching the masked domain character count to their company domain. Based upon reconnaissance efforts, also we knew the company’s email format was {first initial}{last name}@domain.tld. A quick search on LinkedIn did not reveal anyone with a first name starting with “C” and the last name starting with “B.”

At this point, some hackers may abandon trying but any motivated hacker would not. We always take the route of motivation and we automated the Twitter registration process to see if the given email addresses were already associated with one on file with Twitter. Then we brute-forced the user registration form most common last names in the United States. This required us to automated the Twitter registration process using Burp Suite’s Intruder tool to see if any email address we guessed was associated with one on file with Twitter. To generate the list of email addresses, we followed the format c{last name}@domain.tld, and we ran through a list of the most common last names in the United States that begin with the letter “b.” Sure enough, we got a hit.

After confirming that this email address was linked to the account we were targeting, we were ready to social engineer the target. We set up a reverse proxy phishing site using the mitmproxy tool to interface between the target and Twitter to capture their session cookies and bypass MFA. Using a phishing domain that looked like one owned by Twitter, we masked it using Twiter’s t.co masking service. We masqueraded as a fellow employee asking the target to retweet something on the company’s Twitter account. Our email piggybacked off another email to provide context that would make the conversation appear less suspicious.

The target visited the link, authenticated, and entered their MFA token as we successfully captured their session cookies. Due to the nature of the reverse proxy attack, the victim was unaware that anything malicious happened.

Phishing Attacks from Within Show Gaps in Standard Email Security Training

In conducting this phishing attack, we were able to show our client the importance of implementing robust authentication methods like hardware-based multi-factor authentication, which would have made this attack much more difficult, or even impossible, to perform. This attack also demonstrated the importance of not relying solely on security awareness training because employees trust their coworkers, which still leaves companies vulnerable to social engineering attacks.

It is also essential for security leaders to consider how and where information gets leaked, be aware of the consequences of leaded information, and limit as much exposure as possible. For example, test the “Forgot Password” functionality to see how it works and question how it could be abused and how to mitigate it. One mitigation strategy is to audit the privacy and security settings on websites to reduce information leaks. Another mitigation strategy would be to avoid using individual employee accounts to register corporate social media accounts. Instead, register them to an unlisted and unguessable email address solely for that service.

Email Interception through Typosquatting

It is human nature to make mistakes. Human errors become relevant to hackers when email addresses are mistyped. Quite often, these typographical errors appear minor at first glance. For example, imagine the intended domain in the email address is somecompany.com. Several mistakes can happen when typing that in a rush:

  • Swapped letters: someocmpany.com
  • Repeated letters: someecompany.com
  • Missing letters: somecompay.com (missing an ‘n’)
  • Wrong TLD: somecompany.co

It is a standard red teaming practice to look for typosquatting candidate domains for a client’s domain and register them if someone has not already done so. Given enough time, we can often intercept emails that contain sensitive information. In one red teaming engagement, we intercepted credentials for the network visibility and cloud-based WAN platform Aryaka that our client had registered.

Without hesitation, we authenticated and found that our client was already making heavy use of the platform and the user we gained access to was an administrator. The administrator account had access to the entire directory of users, which included full names, email addresses, and telephone numbers.

This privileged access to employee information and network infrastructure details was useful for attacks and allowed us to pivot into their enterprise network.

We could offer several examples of domain name hijacking; one that comes to mind was for an industry-leading provider of transportation services where we registered several typosquatting domains to intercept emails. Most of examples are difficult to show without revealing confidential information, but the image below is one where we learned a lot that could prove useful for social engineering because we had access to specific details that only company insiders would be expected to know.

We have redacted several pieces of information to protect our client’s security. However, behind the redactions are numerous bits of information useful for an attacker, depending on their motives. The screenshot shows how we got the relationships between employees, randomized usernames, a mainframe terminal window, trailer numbers, and more. While each piece on its own might not be critical, together, they helped form a larger picture that carried our attacks forward and could have resulted in devastating consequences for the company if we were a malicious attacker.

Prevent Typosquatting by Registering Similar Domains

In every case where typosquatting domains are used, we hand over these domains to our clients. We also strongly encourage our clients and all other companies to be proactive in registering as many typosquatting domains as possible and using every legal means available to take control of domains already register to malicious actors.

Smishing Attacks Go Beyond Email Phishing

SMS Phishing, or “Smishing,” is a form of social engineering where hackers use text messages to attack people or organizations. It can be surprisingly straightforward to obtain credentials from users or ask targets to install malicious mobile applications by masquerading as a trustworthy entity through SMS messages. A successful Smishing attack gives attackers access to organizational assets such as VPN networks or social media accounts. Smishing can be made more believable by incorporating impersonation techniques like number spoofing. Our experience shows that integrating current events or special knowledge can make the attack less threatening and generally more believable. This common social engineering manipulation tactic, along with a sense of urgency and the “always-on” nature of mobile phones, makes some people feel pressure to engage, increasing the chances of success for an attacker.

In one engagement, we learned that our client required employees to either be on-site or connected to a corporate VPN to access corporate resources. After investigating the web application placed in front of the VPN, we found it offered a mobile page. We also discovered that the company permitted employees to access the VPN from their phones, albeit with limited access rights.

We created a phishing website that ran a reverse proxy with mitmproxy that allowed employees to authenticate to the real VPN site through the reverse proxy. If an employee authenticated through our reverse proxy phishing site, we captured the session cookies and hijacked the session even if they had multi-factor authentication in the form of a time-based one-time password (TOTP).

We strategically sent nine employees the following text message from a phone number in their area, playing off the fact that a hurricane was approaching:

Hey [first name], due to Irma, please verify your VPN access tonight: https://vpn[redacted].com It Should work on mobile. If not, let IT know tomorrow. Thanks

Two employees fell victim to this, and we obtained their credentials, MFA token, and active session cookies.

The VPN only permitted one session at a time, and we lost access quickly, so we needed a new MFA token. We knew the office would be closed the following day due to the hurricane, so we had the following conversation over text message:

Initially, the employee was rightfully suspicious and asked us to call him. But by claiming to be a new employee that wanted to go home ahead of the hurricane, we established trust and were able to gain access to their corporate VPN. Notably, the targeted employee was a network engineer, demonstrating that anyone can fall victim to the right ploy. This red team engagement further emphasizes the need for security awareness at all levels in an organization.

Once we gained access to their corporate VPN, we noticed that entry from personal devices resulted in minimal access to internal resources. The company’s intention was to provide access only to key assets like email, the internal wiki, and the help desk.

Despite the restricted access, we managed to uncover configuration files and credentials for networking equipment by going through the victim’s email, which proved valuable in later assessment phases. We found several hostnames and credentials for internal services like Remote Desktop Protocol (RDP) and web applications, but restrictive VPN policies prevented us from accessing them. That was until we found a Jenkins endpoint, which was mistakenly permitted for personal device connections.

From here, we pivoted to multiple internal servers regardless of VPN policy and established a persistent backdoor in their internal network. Later on, we gained access to the company’s password vault, unlocking the keys to all their business-critical data and assets.

On a different red teaming engagement, we began by obtaining a print out of over 300 employee records through on-site dumper diving that included employees’ full names, department, titles, and mobile phone numbers.

We purchased a domain to masquerade as a new endpoint for their VPN through a reverse proxy that pointed to their real VPN endpoint. We sent an SMS phishing message to 63 employees on this list.

Four victims provided their credentials to the reverse proxy, and we were able to gain access to the company’s VPN and their Centrify SSO Portal. This gave us access to business-critical data, including customer data and critical details about wire transfers in the range of tens of millions of dollars.

In a financially motivated attack, hackers could coordinate a situation to walk away with irreversible wire transfers worth millions of dollars. Attacks like this happened in 2015 and 2016 when North Korean hackers managed to infiltrate banks and initiate wire transfers that resulted in the loss of $101 million.

By continuing this attack, we exposed another gap in the client’s security – an insufficient incident response. Only one victim we targeted with smishing became suspicious and reported the attack.

The active sessions for the services we compromised remained active for several days, despite this report and an investigation, including sessions for Centrify, OWA, and Gmail. We decided to challenge the client’s security further by enrolling our device to the Duo Security two-factor authentication application by creating a service ticket.

This phishing attack demonstrates just how far hackers can and will go to compromise valuable company data.

In-Depth Security Awareness Training Is Valuable at All Levels of an Organization’s Hierarchy

The examples of our team’s findings in this article demonstrate how red teaming tactics can expose gaps in an organizations’ security program. These attacks focused on a company’s biggest weakness – its employees – to show that in-depth security awareness training is valuable at all levels of an organization’s hierarchy.

Despite challenges posed by the increasing Bring Your Own Device (BYOD) model, mitigations do exist to combat these threats. Concerning BYOD, mitigations typically rely on employee awareness and detection capabilities. Keeping these concerns top of mind, organizations can use the following list of actionable advice to move in the right direction.

4 Ways to Prevent Social Engineering Attacks

Set communication policies and expectations

  • Doing this tells employees how to regulate the methods, tone, and language of communication they can expect from the organization. One example is to make it a company policy that official announcements will never come through SMS messages or voice phone calls, and employees will never be asked to visit links sent to them by SMS messages.

Train employees on SMS phishing

  • Train employees to never tap on links in SMS messages, especially those related to work functions. Even if your organization does not use personal cell phones, hackers will still target them on personal devices. It is beneficial if employees are adequately trained to know that their company would never use SMS for official communications. When employees are trained for this, an attacker attempting to use SMS for their attack would raise alarms from employees.

Make reporting suspicious activity easy

  • Have clear procedures for reporting suspicious SMS messages. For example, employees could be trained to take a screenshot of the suspicious SMS and send that to [email protected]. The company could also set up an SMS number that suspicious text messages can be forwarded to be investigated.

Monitor for suspicious logins

  • Improve detection capabilities by monitoring for suspicious logins from locations that are unusual for each employee. For example, if employees typically authenticate from San Francisco and that employee account has a session active in Germany, this should raise flags.

While this list provides valuable information, keep in mind that it is not an exhaustive set of recommendations, especially since security is not a one-size-fits-all package. The best way to protect your organization from malicious threats is through tailored approaches to your specific threat and risk model.

Check out our other article in this series:
Attacking Your Assumptions: How Criminal Tactics Can Save Your Organization

Risk-Based Security Assessments, Like Red Teaming, Expose Security Awareness Training Gaps

VerSprite’s Offensive Security team focuses on emulating cybercrime and simulating test scenarios that not only reflect current attack patterns, but also threat motives. Our team can perform risk-based penetration testing, vulnerability assessments, red teaming exercises, and custom organizational threat models. Contact Our Security Advisors To Learn More About Risk-Based Defense→

The post Security Awareness Training VS Social Engineering Techniques appeared first on Versprite.

QUALITY – INDUSTRY STANDARDS – TRUST

✇VerSprite
bigdrop

At VerSprite, we are dedicated to providing quality and value to our customers and to advancing the cybersecurity industry and its resilience. That is why VerSprite is proud to be accredited by CREST since 2019 for penetration testing.

What is CREST?

CREST is an international accreditation body representing cybersecurity globally.

CREST builds trust in the digital world by raising professional standards and delivering measurable quality assurance for the global cyber security industry. CREST was established in 2006 with a goal to help create a secure digital world for all by certifying its members in penetration testing, incident response, threat intelligence, and security operation centers. This year the organization expended its accreditation scope to include OVS (OWASP Verification Standard) which elevated web and application security to a new level. You can learn more about OVS in our previous blog here.

CREST has managed to build trust and confidence in the cyber community by holding its member companies to high standards of professionalism, competency, and quality of services.

The accreditation process is rigorous and robust. It requires companies to meet the requirements of operating procedures and standards, personnel security and development, approach to testing and response, and data security. All accredited companies sign CREST’s Code of Conduct further helping to ensure consistent quality of provided services.

Why Accreditation Matters?

The cyberthreat landscape is continuously evolving with cybercriminals pushing the limits and finding new paths around established security procedures and frameworks. Simply staying up to date with developments and compliant with traditional security measures will not drive the industry forward or safeguard organizations and practices. To have a competitive edge against threat actors, the cyber industry must stay motivated to adopt innovative and adversarial approach. VerSprite has long recognized it and made innovation a part of its mission. Our team is dedicated first and foremost to staying ahead of cybercriminals and having a black-hat mindset. Receiving and upholding the accreditation from CREST is a recognition of VerSprite’s continuous efforts in cybersecurity.

CREST’s accreditation standards are regularly evaluated and checked against new cyber trends.  Chief Product Officer of VerSprite and a member of CREST Americas council Evin Hernandez comments, “CREST provides the confidence that penetration testing, threat intelligence, and cyber incident response services will be carried out by qualified individual with up-to-date knowledge, skills, and competence, supported by a professional services company with appropriate data handling processes, quality assurance policies, and technical methodologies. It also provides an independent complaints process, tied to the company and individual Codes of Conduct. The CREST website helps buyers distinguish organizations from one another based on skills and competencies.”

CREST standards make sure its members bring quality and value to their customers, and in turn, customers can be confident choosing one of the accredited companies for their cybersecurity needs. VerSprite’s dedication to providing high-quality integrated cybersecurity solutions for our clients earned the company its place as one of CREST’s 300 members, approved for Pen Testing. Our Penetration Testing, a service offered since 2007, is a cybercriminal-approached exercise that centers around collaborative, imaginative crew as well as a global team, plugged into evolutionary attack patterns that reflect an ever-evolving threat actor.

Risk-Based Security Assessments Expose Vulnerabilities

VerSprite’s Offensive Security team focuses on emulating cybercrime and simulating test scenarios that not only reflect current attack patterns, but also threat motives. Our team can perform risk-based penetration testing, vulnerability assessments, red teaming exercises, and custom organizational threat models.

The post QUALITY – INDUSTRY STANDARDS – TRUST appeared first on Versprite.

❌