Messages récents

Pages: [1] 2 3 4 5 6 7 8 ... 10
1
News / [FireEye]Bring Your Own Land (BYOL) – A Novel Red Teaming Technique
« Dernier message par igor51 le Aujourd'hui à 18:59:36 »
Bring Your Own Land (BYOL) – A Novel Red Teaming Technique

Introduction


 

One of most significant recent developments in sophisticated
  offensive operations is the use of “Living off the Land” (LotL)
  techniques by attackers. These techniques leverage legitimate tools
  present on the system, such as the PowerShell scripting language, in
  order to execute attacks. The popularity of PowerShell as an offensive
  tool culminated in the development of entire Red Team frameworks based
  around it, such as Empire and   href="https://github.com/PowerShellMafia/PowerSploit">PowerSploit.
  In addition, the execution of PowerShell can be obfuscated through the
  use of tools such as “  href="https://github.com/danielbohannon/Invoke-Obfuscation">Invoke-Obfuscation”.
  In response, defenders have developed detections for the malicious use
  of legitimate applications. These detections include suspicious
  parent/child process relationships, suspicious process command line
  arguments, and even deobfuscation of malicious PowerShell scripts
  through the use of Script Block Logging.


 

In this blog post, I will discuss an alternative to current LotL
  techniques. With the most current build of Cobalt Strike (version
  3.11), it is now possible to execute .NET assemblies entirely within
  memory by using the “execute-assembly” command. By developing custom
  C#-based assemblies, attackers no longer need to rely on the tools
  present on the target system; they can instead write and deliver their
  own tools, a technique I call Bring Your Own Land (BYOL). I will
  demonstrate this technique through the use of a custom .NET assembly
  that replicates some of the functionality of the PowerSploit project.
  I will also discuss how detections can be developed around BYOL techniques.


 

Background


 

At DerbyCon last year, I had the pleasure of meeting Raphael Mudge,
  the developer behind the Cobalt Strike Remote Access Tool (RAT).
  During our discussion, I mentioned how useful it would be to be able
  to load .NET assemblies into Cobalt Strike beacons, similar to how
  PowerShell scripts can be imported using the “powershell-import”
  command. During a previous Red Team engagement I had been involved in,
  the use of PowerShell was precluded by the Endpoint Detection and
  Response (EDR) agent present on host machines within the target
  environment. This was a significant issue, as much of my red teaming
  methodology at the time was based on the use of various PowerShell
  scripts. For example, the “Get-NetUser” cmdlet of the   href="https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1">PowerView
  script allows for the enumeration of domain users within an Active
  Directory environment. While the use of PowerShell was not an option,
  I found that no application-based whitelisting was occurring on hosts
  within the target’s environment. Therefore, I started converting the
  PowerShell functionality into C# code, compiling assemblies locally as
  Portable Executable (PE) files, and then uploading the PE files onto
  target machines and executing them. This tactic was successful, and I
  was able to use these custom assemblies to elevate privileges up to
  Domain Admin within the target environment.


 

Raphael agreed that the ability to load these assemblies in-memory
  using a Cobalt Strike beacon would be useful, and about 8 months later
  this functionality was incorporated into Cobalt Strike version 3.11
  via the “execute-assembly” command.


 

“execute-assembly” Demonstration


 

For this demonstration, a custom C# .NET assembly named “get-users”
  was used. This assembly replicated some of the functionality of the
  PowerView “Get-NetUser” cmdlet; it queried the Domain Controller of
  the specified domain for a list of all current domain accounts.
  Information obtained included the “SAMAccountName”, “UserGivenName”,
  and “UserSurname” properties for each account. The domain is specified
  by passing its FQDN as an argument, and the results are then sent to
  stdout. The assembly being executed within a Cobalt Strike beacon is
  shown in Figure 1.


 


 
 
 Figure 1: Using the “execute-assembly”
    command within a Cobalt Strike beacon.


 

Simple enough, now let’s take a look at how this technique works
  under the hood.


 

How “execute-assembly” Works


 

In order to discover more about how the “execute-assembly” command
  works, the execution performed in Figure 1 was repeated with the host
  running   href="https://docs.microsoft.com/en-us/sysinternals/downloads/procmon">ProcMon.
  The results of the process tree from ProcMon after execution are shown
  in Figure 2.


 


 
 
 Figure 2: Process tree from ProcMon after
    executing “execute-assembly” command.


 

In Figure 2, The “powershell.exe (2792)” process contains the
  beacon, while the “rundll32.exe (2708)” process is used to load and
  execute the “get-users” assembly. Note that “powershell.exe” is shown
  as the parent process of “rundll32.exe” in this example because the
  Cobalt Strike beacon was launched by using a PowerShell one-liner;
  however, nearly any process can be used to host a beacon by leveraging
  various process migration techniques. From this information, we can
  determine that the “execute-assembly” command is similar to other     href="https://blog.cobaltstrike.com/2016/07/22/why-is-rundll32-exe-connecting-to-the-internet/">Cobalt
    Strike post-exploitation jobs. In Cobalt Strike, some functions
  are offloaded to new processes, in order to ensure the stability of
  the beacon. The rundll32.exe Windows binary is used by default,
  although this setting can be changed. In order to migrate the
  necessary code into the new process, the     id="OLE_LINK20">  id="OLE_LINK19">CreateRemoteThread function is used. We can
  confirm that this function is utilized by monitoring the host with   href="https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon">Sysmon
  while the “execute-assembly” command is performed. The event generated
  by the use of the CreateRemoteThread function is shown in Figure 3.


 


 
 
 Figure 3: CreateRemoteThread Sysmon
    event, created after performing the “execute-assembly” command.


 

More information about this event is shown in Figure 4.


 


 
 
 Figure 4: Detailed information about the
    Sysmon CreateRemoteThread event shown in Figure 3.


 

In order to execute the provided assembly, the Common Language
  Runtime (CLR) must be loaded into the newly created process. From the
  ProcMon logs, we can determine the exact DLLs that are loaded during
  this step. A portion of these DLLs are shown in Figure 5.


 


 
 
 Figure 5: Example of DLLs loaded into
    rundll32 for hosting the CLR.


 

In addition, DLLs loaded into the rundll32 process include those
  necessary for the get-users assembly, such as those for LDAP
  communication and Kerberos authentication. A portion of these DLLs are
  shown in Figure 6.


 


 
 
 Figure 6: Example of DLLs loaded into
    rundll32 for Kerberos authentication.


 

The ProcMon logs confirm that the provided assembly is never written
  to disk, making the “execute-assembly” command an entirely in-memory attack.


 

Detecting and Preventing “execute-assembly”


 

There are several ways to protect against the “execute-assembly”
  command. As previously detailed, because the technique is a
  post-exploitation job in Cobalt Strike, it uses the CreateRemoteThread
  function, which is commonly detected by EDR solutions. However, it is
  possible that other implementations of BYOL techniques would not
  require the use of the CreateRemoteThread function.


 

The “execute-assembly” technique makes use of the native LoadImage
  function in order to load the provided assembly. The   href="https://github.com/endgameinc/ClrGuard">CLRGuard project
  hooks into the use of this function, and prevents its execution. An
  example of CLRGuard preventing the execution of the “execute-assembly”
  command is shown in Figure 7.


 


 
 
 Figure 7: CLRGuard blocking the execution
    of the “execute-assembly” technique.


 

The resulting error is shown on the Cobalt Strike teamserver in
  Figure 8.


 


 
 
 Figure 8: Error shown in Cobalt Strike
    when “execute-assembly” is blocked by CLRGuard.


 

While CLRGuard is effective at preventing the “execute-assembly”
  command, as well as other BYOL techniques, it is likely that blocking
  all use of the LoadImage function on a system would negatively impact
  other benign applications, and is not recommended for production environments.


 

As with almost all security issues, baselining and correlation is
  the most effective means of detecting this technique. Suspicious
  events to correlate could include the use of the LoadImage function by
  processes that do not typically utilize it, and unusual DLLs being
  loaded into processes.


 

Advantages of BYOL


 

Due to the prevalent use of PowerShell scripts by sophisticated
  attackers, detection of malicious PowerShell activity has become a
  primary focus of current detection methodology. In particular, version
  5 of PowerShell allows for the use of     href="https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html">Script
    Block Logging, which is capable of recording exactly what
  PowerShell scripts are executed by the system, regardless of
  obfuscation techniques. In addition, Constrained Language mode can be
  used to restrict PowerShell functionality. While bypasses exist for
  these protections, such as PowerShell downgrade attacks, each bypass
  an attacker attempts is another event that a defender can trigger off
  of. BYOL allows for the execution of attacks normally performed by
  PowerShell scripts, while avoiding all potential PowerShell-based
  alerts entirely.


 

PowerShell is not the only native binary whose malicious use is
  being tracked by defenders. Other common binaries that can generate
  alerts on include WMIC, schtasks/at, and reg. The functionality of all
  these tools can be replicated within custom .NET assemblies, due to
  the flexibility of C# code. By being able to perform the same
  functionality as these tools without using them, alerts that are based
  on their malicious use are rendered ineffective.


 

Finally, thanks to the use of reflective loading, the BYOL technique
  can be performed entirely in-memory, without the need to write to disk.


 

Conclusion


 

BYOL presents a powerful new technique for red teamers to remain
  undetected during their engagements, and can easily be used with
  Cobalt Strike’s “execute-assembly” command. In addition, the use of C#
  assemblies can offer attackers more flexibility than similar
  PowerShell scripts can afford. Detections for CLR-based techniques,
  such as hooking of functions used to reflectively load assemblies,
  should be incorporated into defensive methodology, as these attacks
  are likely to become more prevalent as detections for LotL techniques mature.


 

Acknowledgement


 

Special thanks to Casey Erikson, who I have worked closely with on
  developing C# assemblies that leverage this technique, for his
  contributions to this blog.


Source: Bring Your Own Land (BYOL) – A Novel Red Teaming Technique
2
New FastTrack benefit: Deployment support for Co-management on Windows 10 devices

This blog is part of a series that responds to common questions we receive from customers about deployment of Microsoft 365 security solutions. In this series youll find context, answers, and guidance for deployment and driving adoption within your organization. Check out our last blog Getting the most value out of your security deployment. We

Read more


Source: New FastTrack benefit: Deployment support for Co-management on Windows 10 devices
3
News / [Sophos]Firefox fixes critical buffer overflow
« Dernier message par igor51 le Aujourd'hui à 18:00:07 »
Firefox fixes critical buffer overflow

Version 60.0.2 of the resurgent Firefox browser fixes a critical security flaw in its SVG rendering code.
Source: Firefox fixes critical buffer overflow
4
STF Consulting celebrates 18 years in business, credits Managed Workplace for smart growth | Avast Business

The Company


Recognized by CRN as a top managed service provider (MSP), STF Consulting provides customized IT services and security to small and medium-sized businesses (SMBs) and enterprises in the Monmouth, Ocean, and Middlesex counties of New Jersey.

Sean Furman, president of STF Consulting, started the company in 2000 with just one client. He now has a staff of seven and points to his company’s specialized focus for its success. Says Sean, “We are a real boutique provider and have always worked with clients through an exclusive contract-based model. Our clients have high expectations, and our model provides the right foundation for high-quality services through one contract, so deliverables are clear and achievable. This also enables us to be very proactive and easily add new services as clients evolve their businesses.”


Source: STF Consulting celebrates 18 years in business, credits Managed Workplace for smart growth | Avast Business
5
News / [Sophos]Apple code signing flaw could have made Mac malware look legit
« Dernier message par igor51 le Aujourd'hui à 17:00:03 »
Apple code signing flaw could have made Mac malware look legit

For years it was possible to fool some security software into thinking malicious code had been digitally signed by Apple.
Source: Apple code signing flaw could have made Mac malware look legit
6
News / [kreb]Google to Fix Location Data Leak in Google Home, Chromecast
« Dernier message par igor51 le Aujourd'hui à 17:00:03 »
Google to Fix Location Data Leak in Google Home, Chromecast

Google in the coming weeks is expected to fix a location privacy leak in two of its most popular consumer products. New research shows that Web sites can run a simple script in the background that collects precise location data on people who have a Google Home or Chromecast device installed anywhere on their local network.
Source: Google to Fix Location Data Leak in Google Home, Chromecast
7
News / [Eset]New Telegram-abusing Android RAT discovered in the wild
« Dernier message par igor51 le Aujourd'hui à 16:00:04 »
New Telegram-abusing Android RAT discovered in the wild

Entirely new malware family discovered by ESET researchers
The post New Telegram-abusing Android RAT discovered in the wild appeared first on WeLiveSecurity

Source: New Telegram-abusing Android RAT discovered in the wild
8
The “world’s worst” smart padlock – it’s EVEN WORSE than we thought

Remember last week's $99 IoT padlock that anyone could unlock in 2 seconds? Turns out you don't even need that long!
Source: The “world’s worst” smart padlock – it’s EVEN WORSE than we thought
9
News / [Sophos]Convicted! Anonymous Twitter troll not as anonymous as they thought
« Dernier message par igor51 le Aujourd'hui à 15:00:03 »
Convicted! Anonymous Twitter troll not as anonymous as they thought

It's surprising how many trolls don't realise that if Twitter knows who they are, the police can find out too.
Source: Convicted! Anonymous Twitter troll not as anonymous as they thought
10
News / [Sophos]Dark Web drug dealer betrayed by his beard, pleads guilty
« Dernier message par igor51 le Aujourd'hui à 14:00:06 »
Dark Web drug dealer betrayed by his beard, pleads guilty

The Dream Market's lustrously bearded 'OxyMonster' is facing a 20 year prison sentence.
Source: Dark Web drug dealer betrayed by his beard, pleads guilty
Pages: [1] 2 3 4 5 6 7 8 ... 10