Your business is in a race against modern adversaries — and legacy approaches to security simply do not work in blocking their evolving attacks. Fragmented point products are too slow and complex to deliver the threat detection and prevention capabilities required to stop today’s adversaries — whose breakout time is now measured in minutes — with precision and speed.
As technologies change, threat actors are constantly refining their techniques to exploit them. CrowdStrike is committed to driving innovation for our customers, with a relentless focus on building and delivering advanced technologies to help organizations defend against faster and more sophisticated threats.
CrowdStrike is collaborating with NVIDIA in this mission to accelerate the use of state-of-the-art analytics and AI in cybersecurity to help security teams combat modern cyberattacks, including AI-powered threats. The combined power of the AI-native CrowdStrike Falcon® XDR platform and NVIDIA’s cutting-edge computing and generative AI software, including NVIDIA NIM, delivers the future of cybersecurity with community-wide, AI-assisted protection with the organizational speed and automation required to stop breaches.
“Cybersecurity is a data problem; and AI is a data solution,” said Bartley Richardson, NVIDIA’s Director of Cybersecurity Engineering and AI Infrastructure. “Together, NVIDIA and CrowdStrike are helping enterprises deliver security for the generative AI era.”
AI: The Great Equalizer
Advancements in generative AI present a double-edged sword in the realm of cybersecurity. AI-powered technologies create an opportunity for adversaries to develop and streamline their attacks, and become faster and stealthier in doing so.
Having said that, AI is the great equalizer for security teams. This collaboration between AI leaders empowers organizations to stay one step ahead of adversaries with advanced threat detection and response capabilities. By coupling the power of CrowdStrike’s petabyte-scale security data with NVIDIA’s accelerated computing infrastructure and software, including new NVIDIA NIM inference microservices, organizations are empowered with custom and secure generative AI model creation to protect today’s businesses.
Figure 1. Use Case: Detect anomalous IPs with Falcon data in Morpheus
Driving Security with AI: Combating the Data Problem
CrowdStrike creates the richest and highest fidelity security telemetry, on the order of petabytes daily, from the AI-native Falcon platform. Embedded in the Falcon platform is a virtuous data cycle where cybersecurity’s very best threat intelligence data is collected at the source, preventative and generative models are built and trained, and CrowdStrike customers are protected with community immunity. This collaboration helps Falcon users take advantage of AI-powered solutions to stop the breach, faster than ever.
Figure 2. Training with Morpheus with easy-to-use Falcon Fusion workflow automation
Figure 3. Query Falcon data logs for context-based decisions on potential ML solutions
Joint customers can meet and exceed necessary security requirements — all while increasing their adoption of AI technologies for business acceleration and value creation. With our integration, CrowdStrike can leverage NVIDIA accelerated computing, including the NVIDIA Morpheus cybersecurity AI framework and NVIDIA NIM, to bring custom LLM-powered applications to the enterprise for advanced threat detection. These AI-powered applications can process petabytes of logs to help meet customer needs such as:
Improving threat hunting: Quickly and accurately detect anomalous behavior indicating potential threats, and search petabytes of logs within the Falcon platform to find and defend against threats.
Identifying supply chain attacks: Detect supply chain attack patterns with AI models using high-fidelity security telemetry across cloud, identities and endpoints.
Protecting against vulnerabilities: Identify high-risk CVEs in seconds to determine whether a software package includes vulnerable or exploitable components.
Figure 4. Model evaluation and prediction with test data
The Road Ahead
The development work undertaken by both CrowdStrike and NVIDIA underscores the importance of advancing AI technology and its adoption within cybersecurity. With our strategic collaboration, customers benefit from having the best underlying security data to operationalize their selection of AI architectures with confidence to prevent threats and stop breaches.
At NVIDIA’s GTC conference this year, we highlighted the bright future ahead for security professionals using the combined power of Falcon data with NVIDIA’s advanced GPU-optimized AI pipelines and software. This enables customers to turn their enterprise data into powerful insights and actions to solve business-specific use cases with confidence.
By continuing to pioneer innovative approaches and delivering cutting-edge cybersecurity solutions for the future, we forge a path toward a safer world, ensuring our customers remain secure in the face of evolving cyber threats.
CrowdStrike is proud to announce its official sponsorship of the Mac Admins Community through its not-for-profit arm, the Mac Admins Foundation. CrowdStrike joins a distinguished list of sponsors at the highest level.
The Mac Admins Foundation serves as a vibrant hub of collaboration, information sharing and professional growth for the Mac Admins Community. Founded in 2015 and with more than 40,000 members, the Mac Admins Foundation provides a “global online community of IT professionals who specialize in Apple hardware and software.” The community is an amazing network of peers committed to helping each other learn and grow when it comes to all things related to macOS devices.
This focus on community aligns perfectly with the CrowdStrike ethos. CrowdStrike is built on the power of the crowd. Our community consists of tens of thousands of customers, partners and security practitioners around the world dedicated to defeating adversaries, defending our estates and stopping breaches.
Also aligned with the CrowdStrike ethos is the focus on innovation. Members of the Mac Admins Community are constantly creating — new ideas, businesses and applications — on their machines. CrowdStrike is also relentlessly working to strengthen organizations’ defenses against evolving cyberattacks without getting in the way of great work. We are proud to know today’s innovators are turning to CrowdStrike to secure their best, most critical work.
We’re excited to join these two powerful communities to learn from and support each other on our shared missions.
CrowdStrike: Dedicated to Protecting macOS Devices and Stopping Breaches
MacOS has become a frequent target of cyberattacks as it has increased in popularity for business and enterprise applications. While the macOS provides strong security features, adversaries continue to develop malware specifically targeting macOS, including ransomware, backdoors and trojans.
CrowdStrike is dedicated to protecting the macOS community and devices through research and technology. CrowdStrike researchers continue to track a growing number of attackstargeting macOS devices. The CrowdStrike Falcon® platform delivers industry-leading protection against a broad spectrum of attacks targeting macOS — from commodity and zero-day malware, ransomware and exploits to advanced malware-free and fileless attacks.
CrowdStrike continually participates in third-party testing to demonstrate the efficacy of the Falcon platform in protecting against macOS threats. In 2023, CrowdStrike Falcon® Pro for Mac won the AV-Comparatives Approved Mac Security Product award for the sixth consecutive year. During testing, Falcon Pro for Mac achieved 100% protection against Mac malware, with zero false positives and with no observable performance reduction on the Macs used for testing.
During the testing, AV-Comparatives collected 309 Mac malware samples that were representative of what the organization detected being used in the wild during the first half of 2023. Testers inserted USB flash drives containing these malware samples into the Macs, providing the first opportunity for security products to detect and protect against the malware. Any samples that were not detected were then copied to the Mac’s system disk and executed. If a security solution did not detect and neutralize by this stage, it was considered a miss.
Of the 309 Mac malware samples employed during testing, Falcon Pro for Mac had zero misses, providing 100% detection and 100% protection. There were zero false positives recorded. The Mac computers used in testing showed no observable performance reduction thanks to the lightweight Falcon sensor.
Deepening Our Connection to the Mac Community
As a global leader in cybersecurity, our commitment to the Mac community starts by delivering the device protection required to keep businesses running on macOS devices. And through the sponsorship of the Mac Admins Community, we’re extending our support to the amazing Mac Admins and the people behind the devices.
We believe that open and technical communities like Mac Admins drive the collaboration needed to build and scale the core technologies that power the software and devices that millions of people love and that countless businesses run on. We’re thankful for the hard work of the Mac Admins Community and proud to be a sponsor.
Cyber risks for small and medium-sized businesses (SMBs) have never been higher. SMBs face a barrage of attacks, including ransomware, malware and variations of phishing/vishing. This is one reason why the Cybersecurity and Infrastructure Security Agency (CISA) states “thousands of SMBs have been harmed by ransomware attacks, with small businesses three times more likely to be targeted by cybercriminals than larger companies.”
In a desperate attempt to defend themselves, SMBs often turn to traditional antivirus (AV) software and even off-the-shelf consumer AV solutions. But these offerings simply can’t keep up with modern attacks. Referred to as “legacy AV,” these solutions are reactive and only able to defend against known malware or ransomware previously cataloged by the AV provider. This is too slow and reactive to stop modern adversaries. It only takes one attack to slip through legacy defenses to bring a business to a halt, or worse, result in a company-ending event.
Legacy AV is also difficult to manage, especially with limited IT and security staff. The average deployment of these products is three months. In addition, they require quite a bit of tuning and manual configuration to be fully functional, adding to the operational burden of managing and updating legacy security tools.
Uncertain of which cybersecurity offering to buy and then deploy, many businesses throw up their hands in defeat. One poll shows 60% of SMBs use no cybersecurity measures at all.
SMBs deserve cybersecurity that’s simple, affordable and effective. Today, we’re announcing a new release of CrowdStrike Falcon® Go to bring our industry-leading, AI-powered cybersecurity protection to SMBs in a package that’s never been easier to purchase, install or operate.
SMBs Need Cybersecurity That Works
CrowdStrike knows how cybercriminals work and why they target SMBs.We also understand SMBs are often understaffed, resource-constrained and lack in-house security expertise.
Falcon Go delivers award-winning cybersecurity to protect SMBs against ransomware, malware and unknown threats. This simple yet powerful solution leverages modern technology, including machine learning, behavioral detection and AI, to deliver best-in-class protection against the cyber threats of today and tomorrow. With Falcon Go, small businesses can get the same enterprise-grade protection trusted by the world’s largest organizations and governments in a simple user experience designed for their needs.
SMBs no longer need to worry about staying ahead of evolving cyber threats. Powering Falcon Go is the world’s leading AI-native CrowdStrike Falcon® platform, which collects and analyzes trillions of endpoint events per week, giving SMBs the power of the crowd in a solution that even non-technical staff can use to keep their business safe.
While other SMB cybersecurity solutions may offer simplicity, businesses need security that actually stops breaches. The Falcon platform scored 100% ransomware prevention in SE Labs testing, demonstrating that SMB cybersecurity can be both simple and effective.
Frictionless Purchasing and Installation in Seconds
CrowdStrike is making it easy for SMBs to purchase elite protection and quickly protect their company. Starting today, Falcon Go is available on Amazon Business, allowing SMBs to purchase industry-leading cybersecurity from the same website that millions of businesses use to purchase everyday business items.
Once purchased, users can instantly download and install Falcon Go to begin preventing threats with a guided setup wizard that recommends pre-configured protection levels. With Falcon Go, small businesses can immediately see which devices are protected and any threat activity, with guided and automated next steps to resolve security concerns. Falcon Go also makes it easy to expand protection to new devices, allowing the solution to support business growth.
SMBs need simple, fast, modern cybersecurity to stop breaches at a price they can afford. With the release of Falcon Go, small businesses can get AI-powered, award-winning cybersecurity with easy purchasing, installation and operations to stop modern cyberattacks.
To get started with a free trial of Falcon Go, visit the CrowdStrike website.
In this post, he explains how the Windows program runas works and how the netonly flag allows the creation of processes where the local identity differs from the network identity (the local identity remains the same, while the network identity is represented by the credentials used by runas).
Cobalt Strike provides the make_token command to achieve a similar result to runas /netonly.
If you are familiar with this command, you have likely experienced situations in which processes created by Beacon do not “inherit” the new token properly. The inner workings of this command are fairly obscure, and searching Google for something like “make_token cobalt strike” does not provide much valuable information (in fact, it is far more useful to analyse the implementations of other frameworks such as Sliver or Covenant).
“If you are in a privileged context, you can use make_token in Beacon to create an access token with credentials”
“The problem with make_token, as much as steal_token, is it requires you to be in an administrator context before you can actually do anything with that token”
Even though the description does not mention it, Raphael states that make_token requires an administrative context. However, if we go ahead and use the command with a non-privileged user… it works! What are we missing here?
This post aims to shed more light on how the make_token command works, as well as its capabilities and limitations. This information will be useful in situations where you want to impersonate other users through their credentials with the goal of enumerating or moving laterally to remote systems.
It’s important to note that, even though we are discussing Cobalt Strike, this knowledge is perfectly applicable to any modern C2 framework. In fact, for the purposes of this post, we took advantage of the fact that Meterpreter did not have a make_token module to implement it ourselves.
An example of the new post/windows/manage/make_token module can be seen below:
You can find more information about our implementation in the following links:
Let’s begin with some theory about Windows authentication. This will help in understanding how make_token works under the hood and addressing the questions raised in the introduction.
Local Security Context Network Security Context?
Let’s consider a scenario where our user is capsule.corp\yamcha and we want to interact with a remote system to which only capsule.corp\bulma has access. In this example, we have Bulma’s password, but the account is affected by a deny logon policy in our current system.
If we attempt to run a cmd.exe process with runas using Bulma’s credentials, the result will be something like this:
The netonly flag is intended for these scenarios. With this flag we can create a process where we remain Yamcha at the local level, while we become Bulma at the network level, allowing us to interact with the remote system.
In this example, Yamcha and Vegeta were users from the same domain and we could circumvent the deny log on policy by using the netonly flag. This flag is also very handy for situations where you have credentials belonging to a local user from a remote system, or to a domain user from an untrusted domain.
The fundamental thing to understand here is Windows will not validate the credentials you specify to runas /netonly, it will just make sure they are used when the process interacts with the network. That’s why we can bypass deny log on policies with runas /netonly, and also use credentials belonging to users outside our current system or from untrusted domains.
Now… How does runas manage to create a process where we are one identity in the local system, and another identity in the network?
If we extract the strings of the program, we will see the presence of CreateProcessWithLogonW.
A simple lookup of the function shows that runas is probably using it to create a new process with the credentials specified as arguments.
Reading the documentation, we will find a LOGON_NETCREDENTIALS_ONLY flag which allows the creation of processes in a similar way to what we saw with netonly. We can safely assume that this flag is the one used by runas when we specify /netonly.
The Win32 API provides another function very similar to CreateProcessWithLogonW, but without the process creation logic. This function is called LogonUserA.
LogonUserA is solely responsible for creating a new security context from given credentials. This is the function that make_token leverages and is commonly used along with the LOGON32_LOGON_NEW_CREDENTIALS logon type to create a netonly security context (we can see this in the implementations of open source C2 frameworks).
To understand how it is possible to create a process with two distinct “identities” (local/network), it is fundamental to become familiar with two important components of Windows authentication: logon sessions and access tokens.
Logon Sessions Access Tokens
When a user authenticates to a Windows system, a process similar to the image below occurs. At a high level, the user’s credentials are validated by the appropriate authentication package, typically Kerberos or NTLM. A new logon session is then created with a unique identifier, and the identifier along with information about the user is sent to the Local Security Authority (LSA) component. Finally, LSA uses this information to create an access token for the user.
Regarding access tokens, they are objects that represent the local security context of an account and are always associated with a process or thread of the system. These objects contain information about the user such as their security identifier, privileges, or the groups to which they belong. Windows performs access control decisions based on the information provided by access tokens and the rules configured in the discretionary access control list (DACL) of target objects.
An example is shown below where two processes – one from Attl4s and one from Wint3r – attempt to read the “passwords.txt” file. As can be seen, the Attl4s process is able to read the file due to the second rule (Attl4s is a member of Administrators), while the Wint3r process is denied access because of the first rule (Wint3r has identifier 1004).
Regarding logon sessions, their importance stems from the fact that if an authentication results in cached credentials, they will be associated with a logon session. The purpose of cached credentials is to enable Windows to provide a single sign-on (SSO) experience where the user does not need to re-enter their credentials when accessing a remote service, such as a shared folder on the network.
As an interesting note, when Mimikatz dumps credentials from Windows authentication packages (e.g., sekurlsa::logonpasswords), it iterates through all the logon sessions in the system to extract their information.
The following image illustrates the relationship between processes, tokens, logon sessions, and cached credentials:
The key takeaways are:
Access tokens represent the local security context of an authenticated user. The information in these objects is used by the local system to make access control decisions
Logon sessions with cached credentials represent the network security context of an authenticated user. These credentials are automatically and transparently used by Windows when the user wants to access remote services that support Windows authentication
What runas /netonly and make_token do under the hood is creating an access token similar to the one of the current user (Yamcha) along with a logon session containing the credentials of the alternate user (Bulma). This enables the dual identity behaviour where the local identity remains the same, while the network identity changes to that of the alternate user.
As stated before, the fact that runas netonly or make_token do not validate credentials has many benefits. For example we can use credentials for users who have been denied local access, and also for accounts that the local system does not know and cannot validate (e.g. a local user from other computer or an account from an untrusted domain). Additionally, we can create “sacrificial” logon sessions with invalid credentials, which allows us to manipulate Kerberos tickets without overwriting the ones stored in the original logon session.
However, this lack of validation can also result in unpleasant surprises, for example in the case of a company using an authenticated proxy. If we make a mistake when inserting credentials to make_token, or create sacrificial sessions carelessly, we can end up with locked accounts or losing our Beacon because it is no longer able to exit through the proxy!
Administrative Context or Not!?
Raphael mentioned that, in order to use a token created by make_token, an administrative context was needed.
“The problem with make_token, as much as steal_token, is it requires you to be in an administrator context before you can actually do anything with that token”
Do we really need an administrative context? The truth is there are situations where this statement is not entirely accurate.
As far as we know, the make_token command uses the LogonUserA function (along with the LOGON32_LOGON_NEW_CREDENTIALS flag) to create a new access token similar to that of the user, but linked to a new logon session containing the alternate user’s credentials. The command does not stop there though, as LogonUserA only returns a handle to the new token; we have to do something with that token!
Let’s suppose our goal is to create new processes with the context of the new token.
Creating Processes with a Token
If we review the Windows API, we will spot two functions that support a token handle as an argument to create a new process:
Reading the documentation of these functions, however, will show the following statements:
“Typically, the process that calls the CreateProcessAsUser function must have the SE_INCREASE_QUOTA_NAME privilege and may require the SE_ASSIGNPRIMARYTOKEN_NAME privilege if the token is not assignable.”
“The process that calls CreateProcessWithTokenW must have the SE_IMPERSONATE_NAME privilege.”
This is where Raphael’s statement makes sense. Even if we can create a token with a non-privileged user through LogonUserA, we will not be able to use that token to create new processes. To do so, Microsoft indicates we need administrative privileges such as SE_ASSIGNPRIMARYTOKEN_NAME, SE_INCREASE_QUOTA_NAME or SE_IMPERSONATE_NAME.
When using make_token in a non-privileged context and attempting to create a process (e.g., shell dir \dc01.capsule.corp\C$), Beacon will silently fail and fall back to ignoring the token to create the process. That’s one of the reasons why sometimes it appears that the impersonation is not working properly.
As a note, agents like Meterpreter do give more information about the failure:
As such, we could rephrase Raphael’s statement as follows:
“The problem with make_token is it requires you to be in an administrator context before you can actually create processes with that token”
The perceptive reader may now wonder… What happens if I operate within my current process instead of creating new ones? Do I still need administrative privileges?
Access Tokens + Thread Impersonation
The Windows API provides functions like ImpersonateLoggedOnUser or SetThreadToken to allow a thread within a process to impersonate the security context provided by an access token.
In addition to keeping the token handle for future process creations, make_token also employs functions like these to acquire the token’s security context in the thread where Beacon is running. Do we need administrative privileges for this? Not at all.
As can be seen in the image below, we meet point number three:
This means that any command or tool executed from the thread where Beacon is running will benefit from the security context created by make_token, without requiring an administrative context. This includes many of the native commands, as well as capabilities implemented as Beacon Object Files (BOFs).
Closing Thoughts
Considering all the information above, we could do a more detailed description of make_token as follows:
The make_token command creates an access token similar to the one of the current user, along with a logon session containing the credentials specified as arguments. This enables a dual identity where nothing changes locally (we remain the same user), but in the network we will be represented by the credentials of the alternate user (note that make_token does not validate the credentials specified). Once the token is created, Beacon impersonates it to benefit from the new security context when running inline capabilities.
The token handle is also stored by Beacon to be used in new process creations, which requires an administrative context. If a process creation is attempted with an unprivileged user, Beacon will ignore the token and fall back to a regular process creation.
As a final note, we would like to point out that in 2019 Raphael Mudge released a new version of his awesome Red Team Ops with Cobalt Strike course. In the eighth video, make_token was once again discussed, but this time showing a demo with an unprivileged user. While this demonstrated that running the command did not require an administrative context, it did not explain much more about it.
We hope this article has answered any questions you may have had about make_token.
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 …
Login
