Normal view

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

Risk-Centric Threat Models as Blueprints to Operationalizing Cybersecurity

12 October 2022 at 15:39

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 post Risk-Centric Threat Models as Blueprints to Operationalizing Cybersecurity appeared first on VerSprite.

Operationalizing CISA Alerts with Threat Models for Effective Cybersecurity

12 October 2022 at 21:56

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 post Operationalizing CISA Alerts with Threat Models for Effective Cybersecurity appeared first on VerSprite.

A Look at RACI Models within Application Threat Modeling

By: VerSprite
20 October 2022 at 17:26

In this model, you will see engineers, network professionals, developers, architects, business analysts, project managers, security champions, pentesters, and quality assurance engineers. Because they all have some level of involvement and collaboration at different stages of application, as well as organizational, threat modeling ensures effective results.

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

Digital AdTech Firm’s CTO Focuses on Strategic Cybersecurity Alliances to Build Resiliency for Digital Turbine

By: VerSprite
19 December 2022 at 22:36

Digital Turbine, a leader in mobile advertising, chooses VerSprite Enterprise Risk Assessments and Pen testing services to enhance its security framework, identify probable risks, and gain visibility into its expanding attack surfaces associated with new acquisitions.

The post Digital AdTech Firm’s CTO Focuses on Strategic Cybersecurity Alliances to Build Resiliency for Digital Turbine appeared first on VerSprite.

Printer Spooler Bug Research

22 December 2022 at 15:07

In this blog, we dive into and show how attackers could combine the 0day CVE-2020-0986 with the 0day in IE browser to achieve privilege escalation and then execute code remotely. Now, Maddie Stone, a security researcher on Google's Project Zero team, found that an attacker can still trigger CVE-2020-0986 and elevate kernel privileges by sending an offset instead of a pointer.

The post Printer Spooler Bug Research appeared first on VerSprite.

Analyzing the State of Cybersecurity

By: VerSprite
30 December 2022 at 18:57

In this blog, we look back at how the cybersecurity landscape has drastically changed in 2022, what influenced the uptick in cybercrime, and what you need to be aware of to better prepare for the coming year. Our Envisions is a leading threat report, produced by the VerSprite team of cybersecurity analysts, that encompasses cyber trends and geopolitical themes to provide the best expert overview of the state of cybersecurity.

The post Analyzing the State of Cybersecurity appeared first on VerSprite.

Welcome to The World of Geopolitics and Cybersecurity!

27 January 2023 at 16:06

With expert analysis and in-depth research, this eBook covers everything from the role of cyber warfare in international conflicts to the impact of cyber espionage on diplomatic relations, as well as the impact on individual industries. You'll gain a deeper understanding of the motivations behind state-sponsored cyberattacks and the strategies and tactics to defend against them.

The post Welcome to The World of Geopolitics and Cybersecurity! appeared first on VerSprite.

Envisions Threat Report:

7 March 2023 at 22:52

In 2022, the cyber threat landscape caused many industries to falter and weaken in a post-pandemic world. Threat actors identified weaknesses and exploited them. As businesses and individuals attempted to return to a new normal, there was a constant struggle to increase production and services while countering malicious cyber threats.

The post Envisions Threat Report: appeared first on VerSprite.

VerSprite and AppSecEngineer Partner to Operationalize Security Training

By: VerSprite
23 March 2023 at 13:08

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 to equip organizations to handle any security challenges that may arise. “VerSprite has always taken a risk-first approach to cybersecurity, even inventing the PASTA risk methodology,” …

Continue reading "VerSprite and AppSecEngineer Partner to Operationalize Security Training"

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

Nordstream Pipelines Attacks

23 March 2023 at 17:51

Russia – Ukraine Conflict and Its Impact on the Cyber Threat Landscape Bottom Line Up Front (BLUF)    Russia’s attempt to annex parts of Ukraine created a broader contention between nations and drew western nations into the conflict. The sabotage of the Russian Nordstream 1 & 2 pipelines may be an act of further escalation and …

Continue reading "Nordstream Pipelines Attacks"

The post Nordstream Pipelines Attacks appeared first on VerSprite.


By: bigdrop
24 August 2022 at 15:12

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.

Security Awareness Training VS Social Engineering Techniques

By: bigdrop
24 August 2022 at 20:00

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.

Threat Modeling Within Software Development Lifecycle

By: bigdrop
31 August 2022 at 17:10

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.


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.

Cybersecurity and Physical Attacks Against Your Business

By: bigdrop
1 September 2022 at 21:00

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.


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.