Synthetic Memory Protections: An update on ROP mitigations [PDF](https://www.openbsd.org/papers/csw2023.pdf)
π£Gallus
Brief summary leaving out a ton of details:
Looks like OpenBSD is/has introduced some new exploit mitigations that work to hinder ROP-based exploited chains. There are four new mitigations
Immutable mappings (permissions) - Mappings can be marked as immutable so the mappings rwx permissions cannot be modified after that point, nor can the page be unmapped and remapped with different permissions. So you can't use a ROP chain to make some page you can get data in executable.
Xonly - eXecute Only memory - Memory that can be mapped as executable but not readable. Mainly this tries to prevent attacks from being able to find ROP gadgets in the first place, if they can't read the executable code they can't find gadgets. Of course if you have access to the original binaries then you can get the executable data from there, but it prevents Blind ROP style attacks.
I was surprised to see they had an amd64 implementation using the RPKU register (only on newer CPUs). I can't comment much on the implementation since I'm unfamiliar with how that aspect works, but it did surprise me.
There is also a kernel enforced XOM, I'm not sure how effective it will be though. It seems like it just basically validates addresses on
Stack Protection - This one is a meant to prevent stack pivots, which is where you use a ROP gadget to move the stack to a completely new region of memory, usually off the stack somewhere the attacker has more control. To do this pages mapped for the stack get marked, and when there is a syscall the kernel verifies the stack pointer still points to a stack page otherwise it kills the program.
Execute Syscall Protection - Restricts where syscalls can originate from, on syscall the instruction pointer/program counter must point to a region where syscalls are permitted. This prevents chains that create an executable section to dump shellcode into and execute that. Forcing chains to use an existing syscall gadget.
----
Honestly, an interesting set of mitigations. Nothing that is game changing, but as they say, they are all steps that make exploitation most costly and difficult.
π€PM_ME_YOUR_SHELLCODE
π@malwr
π£Gallus
Brief summary leaving out a ton of details:
Looks like OpenBSD is/has introduced some new exploit mitigations that work to hinder ROP-based exploited chains. There are four new mitigations
Immutable mappings (permissions) - Mappings can be marked as immutable so the mappings rwx permissions cannot be modified after that point, nor can the page be unmapped and remapped with different permissions. So you can't use a ROP chain to make some page you can get data in executable.
Xonly - eXecute Only memory - Memory that can be mapped as executable but not readable. Mainly this tries to prevent attacks from being able to find ROP gadgets in the first place, if they can't read the executable code they can't find gadgets. Of course if you have access to the original binaries then you can get the executable data from there, but it prevents Blind ROP style attacks.
I was surprised to see they had an amd64 implementation using the RPKU register (only on newer CPUs). I can't comment much on the implementation since I'm unfamiliar with how that aspect works, but it did surprise me.
There is also a kernel enforced XOM, I'm not sure how effective it will be though. It seems like it just basically validates addresses on
copyin calls. So pure-userland/CPU reads wouldn't trip this check, though I'm sure there are some cases it'll stop.Stack Protection - This one is a meant to prevent stack pivots, which is where you use a ROP gadget to move the stack to a completely new region of memory, usually off the stack somewhere the attacker has more control. To do this pages mapped for the stack get marked, and when there is a syscall the kernel verifies the stack pointer still points to a stack page otherwise it kills the program.
Execute Syscall Protection - Restricts where syscalls can originate from, on syscall the instruction pointer/program counter must point to a region where syscalls are permitted. This prevents chains that create an executable section to dump shellcode into and execute that. Forcing chains to use an existing syscall gadget.
----
Honestly, an interesting set of mitigations. Nothing that is game changing, but as they say, they are all steps that make exploitation most costly and difficult.
π€PM_ME_YOUR_SHELLCODE
π@malwr
π1
Wireshark Experts! I need your help. Does this look like malicious network activity (Spoofing) to you?
The Destination Addresses:
52.112.107.86, 52.112.107.113, 52.112.107.80, and 52.112.107.12 All have the same MAC address: 9c:1e:95:23:2a:70
As does the 52.35.31.120 address.
The 192.168.1.70 and .71 addresses I believe to be a server and client respectively.
Any insight or help would be greatly appreciated!
https://preview.redd.it/7ms5lpdlnjqa1.png?width=2143&format=png&auto=webp&v=enabled&s=67c06172bc714f2f99352f57876e424c2845d932
π£SmiIeyMcgee
With the limited info provided, what I can say is it looks like .70 is running teams and .71 is a computer browsing the internet, possibly a Firefox browser.
https://www.virustotal.com/gui/ip-address/52.35.31.120
Your assumption that these are βthe client and the serverβ appears to be incorrect and they are both hosts on your local network. The 192.168. tells you these are addresses in your local network and would not be a server unless you are running a homelab of some sort.
All of the STUN traffic is contacting Microsoft-owned IP space, over the STUN port, which is used for VOIP as stated by other commenters. The reverse DNS makes it look like a Teams relay.
https://www.virustotal.com/gui/ip-address/52.112.107.86
https://www.speedguide.net/port.php?port=3478
The reason all of the destination MAC addresses are the same is because at that layer, you will only be getting the local destination MAC address, i.e. the local destination of the device routing traffic destined for the internet. Given that the OUI belongs to βActionTek Electronicsβ, Iβd say youβre looking at your routerβs MAC address.
https://www.wireshark.org/tools/oui-lookup.html
https://www.actiontec.com
With the provided information, there is nothing here that is explicitly concerning.
π€mossoakbear
Since you have asked about the MAC address, I'm assuming you're concerned with ARP poisoning? The MAC address for Internet bound traffic, which this is, will all be the same and should match the MAC address for your Default Gateway (Router).
STUN UDP 3478 traffic to that IP space would be normal unless there's other information.https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#skype-for-business-online-and-microsoft-teams
π€TechFemme
It's difficult to give an accurate answer without knowing a bit of background to the investigation but some info that could help...
The STUN protocol is used for VoIP services and the IPs seem to resolve to MS. Do you have a MS Communication Server in your environment? Or any other VoIP service like Skype for business?
The packets are often logged as malformed or don't get decoded as wireshark simply doesn't have the correct decoders for this data. You may be able to find a plugin depending on the service being used.
STUN packets have been exploited for DoS attacks in the past so it could be malicious but there isn't enough data to reach a reliable conclusion here.
What alerted you to this activity in the first place? Any other suspicious or unusual activity within the same timeframe?
π€tommythecoat
π@malwr
The Destination Addresses:
52.112.107.86, 52.112.107.113, 52.112.107.80, and 52.112.107.12 All have the same MAC address: 9c:1e:95:23:2a:70
As does the 52.35.31.120 address.
The 192.168.1.70 and .71 addresses I believe to be a server and client respectively.
Any insight or help would be greatly appreciated!
https://preview.redd.it/7ms5lpdlnjqa1.png?width=2143&format=png&auto=webp&v=enabled&s=67c06172bc714f2f99352f57876e424c2845d932
π£SmiIeyMcgee
With the limited info provided, what I can say is it looks like .70 is running teams and .71 is a computer browsing the internet, possibly a Firefox browser.
https://www.virustotal.com/gui/ip-address/52.35.31.120
Your assumption that these are βthe client and the serverβ appears to be incorrect and they are both hosts on your local network. The 192.168. tells you these are addresses in your local network and would not be a server unless you are running a homelab of some sort.
All of the STUN traffic is contacting Microsoft-owned IP space, over the STUN port, which is used for VOIP as stated by other commenters. The reverse DNS makes it look like a Teams relay.
https://www.virustotal.com/gui/ip-address/52.112.107.86
https://www.speedguide.net/port.php?port=3478
The reason all of the destination MAC addresses are the same is because at that layer, you will only be getting the local destination MAC address, i.e. the local destination of the device routing traffic destined for the internet. Given that the OUI belongs to βActionTek Electronicsβ, Iβd say youβre looking at your routerβs MAC address.
https://www.wireshark.org/tools/oui-lookup.html
https://www.actiontec.com
With the provided information, there is nothing here that is explicitly concerning.
π€mossoakbear
Since you have asked about the MAC address, I'm assuming you're concerned with ARP poisoning? The MAC address for Internet bound traffic, which this is, will all be the same and should match the MAC address for your Default Gateway (Router).
STUN UDP 3478 traffic to that IP space would be normal unless there's other information.https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#skype-for-business-online-and-microsoft-teams
π€TechFemme
It's difficult to give an accurate answer without knowing a bit of background to the investigation but some info that could help...
The STUN protocol is used for VoIP services and the IPs seem to resolve to MS. Do you have a MS Communication Server in your environment? Or any other VoIP service like Skype for business?
The packets are often logged as malformed or don't get decoded as wireshark simply doesn't have the correct decoders for this data. You may be able to find a plugin depending on the service being used.
STUN packets have been exploited for DoS attacks in the past so it could be malicious but there isn't enough data to reach a reliable conclusion here.
What alerted you to this activity in the first place? Any other suspicious or unusual activity within the same timeframe?
π€tommythecoat
π@malwr
Efficient SIEM and Detection Engineering in 10 steps
π£mszymczyk
SIEM is the biggest snake oil of the security industry. It never ceases to amaze me how much of a silver bullet people think it is that will save you from everything. Donβt get me wrong it is a valuable detective control if implemented properly, if done poorly itβs a great way to pour money down the drain.
π€Big_baddy_fat_sack
π@malwr
π£mszymczyk
SIEM is the biggest snake oil of the security industry. It never ceases to amaze me how much of a silver bullet people think it is that will save you from everything. Donβt get me wrong it is a valuable detective control if implemented properly, if done poorly itβs a great way to pour money down the drain.
π€Big_baddy_fat_sack
π@malwr
Medium
Efficient SIEM and Detection Engineering in 10 steps
SIEM systems and detection engineering are not just about data and detection rules. Planning and processes are becoming increasinglyβ¦
This script extracts metadata from image files and returns it as a pandas dataframe. It uses the piexif library to extract metadata from the images, and the geopy library to convert GPS coordinates to place names.
π£DevOpsMuffin39
Interesting. Unnecessary usage of pandas though... why not return a simple object array? Keep the initial data structure simple and let the user decide what to do with it.
π€Fergobirck
Is it good?
π€Fit-Special-8416
π@malwr
π£DevOpsMuffin39
Interesting. Unnecessary usage of pandas though... why not return a simple object array? Keep the initial data structure simple and let the user decide what to do with it.
π€Fergobirck
Is it good?
π€Fit-Special-8416
π@malwr
GitHub
script-toolbox/exif_df.py at main Β· tg12/script-toolbox
This repository contains a collection of scripts and tools that I have written to solve various problems that I have come across. - tg12/script-toolbox
The US Military Cyber Professionals Associatian calls for the creation of a US Cyber Force - the Brits have one and the US want one too
π£digicat
They need to get rid of the space force, and implement a cyber force
π€clear-carbon-hands
As a guy in one of the military cyber forces, please no. The issues with conducting cyber operations wonβt go away if we all wear the same uniform
π€Grumps-Tucan
π@malwr
π£digicat
They need to get rid of the space force, and implement a cyber force
π€clear-carbon-hands
As a guy in one of the military cyber forces, please no. The issues with conducting cyber operations wonβt go away if we all wear the same uniform
π€Grumps-Tucan
π@malwr
public.milcyber.org
MCPA - Legislation
The MCPA calls for the creation of a US Cyber Force!
Disclaimer: The views expressed in this statement do not necessarily reflect the opinions of all organization members, advisors, or partners.
Disclaimer: The views expressed in this statement do not necessarily reflect the opinions of all organization members, advisors, or partners.
Is there a way to make the name field of a global structure wider? I can't read the method names
π£fwork
Yes, one of the buttons on top bar of the listing opens a block of various headers. You can resize those headers just as table headers and by that change the width of the listing contents.
π€d_stroid
π@malwr
π£fwork
Yes, one of the buttons on top bar of the listing opens a block of various headers. You can resize those headers just as table headers and by that change the width of the listing contents.
π€d_stroid
π@malwr
Time Travel Debugging IDA plugin, ttddbg, 1.1.0 is out with new tracing feature ! Based on #IDA database, arguments and return value are pretty-printed !
Enjoy βοΈπ°οΈπ
https://github.com/airbus-cert/ttddbg
π£citronneur
π@malwr
Enjoy βοΈπ°οΈπ
https://github.com/airbus-cert/ttddbg
π£citronneur
π@malwr
π1
π£ Exciting news for all JADX users! π
I've just released an official video guide on how to use my new latest Dynamic Scripting Plugin, JADXecute!
#ReverseEngineering #AndroidDev
https://www.youtube.com/watch?v=g0r3C1iEeBg
π£lauriewired
π@malwr
I've just released an official video guide on how to use my new latest Dynamic Scripting Plugin, JADXecute!
#ReverseEngineering #AndroidDev
https://www.youtube.com/watch?v=g0r3C1iEeBg
π£lauriewired
π@malwr
YouTube
JADXecute: Dynamic Scripting For JADX
Introducing my new tool JADXecute! JADXecute is a plugin for JADX that enhances its functionality by adding Dynamic Code Execution abilities.
With JADXecute, you can dynamically run Java code to modify or print components of the jadx-gui output. JADXecuteβ¦
With JADXecute, you can dynamically run Java code to modify or print components of the jadx-gui output. JADXecuteβ¦
π1
Windows kernel drivers for red team tools development
Introduction series by @Idov31
Part 1: https://idov31.github.io/2022/07/14/lord-of-the-ring0-p1.html
Part 2: https://idov31.github.io/2022/08/04/lord-of-the-ring0-p2.html
Part 3: https://idov31.github.io/2022/10/30/lord-of-the-ring0-p3.html
#windows #kernel #redteam #malware #infosec #cybersecurity #learning
π£0xor0ne
π@malwr
Introduction series by @Idov31
Part 1: https://idov31.github.io/2022/07/14/lord-of-the-ring0-p1.html
Part 2: https://idov31.github.io/2022/08/04/lord-of-the-ring0-p2.html
Part 3: https://idov31.github.io/2022/10/30/lord-of-the-ring0-p3.html
#windows #kernel #redteam #malware #infosec #cybersecurity #learning
π£0xor0ne
π@malwr
I made a writeup on #Magniber #ransomware (from 2022) demonstrating the capabilities of the latest #TinyTracer: https://hshrzd.wordpress.com/2023/03/30/magniber-ransomware-analysis/
π£hasherezade
π@malwr
π£hasherezade
π@malwr
π1
Walk through an incident where initial access was obtained through exploitation of CVE-2023-0669 (Go AnyWhere MFT) a day after the release of the vuln and 4 days before a patch was released. Also, I have some thoughts on vuln adoption by criminals.
https://securityintelligence.com/posts/x-force-prevents-zero-day-from-going-anywhere/
π£TactiKoolSec
π@malwr
https://securityintelligence.com/posts/x-force-prevents-zero-day-from-going-anywhere/
π£TactiKoolSec
π@malwr
β€1π1
Supply chain attack in 3CX Windows Electron DesktopApp
π£qwerty0x41
It should also be noted that the MacOS version was also trojaned. If you have installed 3CXDesktopApp-18.12.416.dmg (SHA1 3DC840D32CE86CEBF657B17CEF62814646BA8E98), you have a trojaned version.
Since it had only one C2 domain hard coded and that is offline, the malware is dormant.
Still, burn it with fire.
π€CrimsonNorseman
Some IOCs posted by a user on the 3CX forum: ~~https://www.3cx.com/community/threads/3cx-icos.119967/#post-559156~~
EDIT: thread was removed, refer to https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/#heading-5 for what seems to be up to date IOCs
π€qwerty0x41
Supply chain? So what dependency was compromised/exploited? Electron itself or a node.js library?
π€iliark
π@malwr
π£qwerty0x41
It should also be noted that the MacOS version was also trojaned. If you have installed 3CXDesktopApp-18.12.416.dmg (SHA1 3DC840D32CE86CEBF657B17CEF62814646BA8E98), you have a trojaned version.
Since it had only one C2 domain hard coded and that is offline, the malware is dormant.
Still, burn it with fire.
π€CrimsonNorseman
Some IOCs posted by a user on the 3CX forum: ~~https://www.3cx.com/community/threads/3cx-icos.119967/#post-559156~~
EDIT: thread was removed, refer to https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/#heading-5 for what seems to be up to date IOCs
π€qwerty0x41
Supply chain? So what dependency was compromised/exploited? Electron itself or a node.js library?
π€iliark
π@malwr
π€1
Bypassing DEP with gap restrictions
π£CarelessOne7933
Like it is a new technique... It's basically what everyone is doing since ever to prevent shellcode corruption
π€Void_Sec
π@malwr
π£CarelessOne7933
Like it is a new technique... It's basically what everyone is doing since ever to prevent shellcode corruption
π€Void_Sec
π@malwr
divyanshu-mehta.gitbook.io
Bypassing DEP - Increasing the Gap
This blog talks about how to use WriteProcessMemory API Call for executing shellcode in a scenario where there is very less gap between shellcode and WriteProcessMemory call skeleton