SINCON 2025
And the rest of Singapore!
Last updated
And the rest of Singapore!
Last updated
I got to attend SINCON 2025 by Infosec In the City on the 22nd and 23rd of May! This coverage was brought to you by SherpaSec, who graciously provided the Full Conference Pass.
Unlike my previous blog entries, I plan to share more of what I've learnt.
This was a workshop hosted by Sim Cher Boon (Gladiator), the Co-founder of Off-by-One and a big name in the Singaporean community, and supported by two prodigies, Lau Jun Yu (Sora) and Zavier Lee (gatari). This was an insanely stacked roster, and their depth of knowledge really showed.
This workshop delved into penetration testing on Active Directory environments, beginning with Cher Boon clearing up some misconceptions; that misconfigurations are not system vulnerabilities, although they are used interchangeably. A vulnerability is more accurately defined as an unintended flaw within the system, such as PrintNightmare exploiting the PrintSpooler services, whereas system misconfigurations, such as an ACL allowing all traffic or reused credentials, are more accurately portrayed as poor implementations of a secure system. This has different implications as to what the attack path could look like. Exploiting the memberOf condition follows a very different philosophy compared to, say, kerberoasting accounts. Misconfigurations in the real world are much more common than vulnerabilities, so it is important to demonstrate the impact and severity of these weaknesses.
Furthermore, the workshop also touched on places where one might be able to get credentials. Some of the places that were highlighted include registry hives (e.g., HKLM, Secrets, Cache, SAM) and in memory in the form of LSASS.
During the session as well, several considerations were brought up, including the fact that if the LSASS is the crown jewel of OS Credential Dumping, then it would be heavily monitored; it just makes sense. Due to the nature of the exploitation (writing from the victim's memory to storage for downloading their creds), this activity cannot be hidden, and if the target's detection is any good, you would very likely be caught. As such, LSASS cred dumping would cause a lot of alerts, and it is one of the most common TTPs when it comes to AD post-exploitation.
To add insult to injury, the workshop mentioned that in Windows 11, there is no longer a way to dump LSASS credentials. As mentioned, a way to circumvent this would be to dump credentials from the browser instead of LSASS, but it wasn't shown how to do so; likely a topic for another day.
The workshop also featured a hands-on Active Directory CTF, whereby each challenge is sequentially linked to the previous. This AD environment contained a Domain Controller, a File Share, and a Developer server, respectively; each with its own vulnerabilities and misconfigurations to be exploited. Due to time limitations, I could only complete 18 out of the 20 challenges. Very simply put, the attack path of the AD PT that was done involved exploitation of guest accounts to enumerate real user accounts, to which lateral movement was performed on several accounts until we gained enough privilege, and then executed mimikatz at the end.
The resources for the workshop itself can be found here:
As per usual, networking equipment is really expensive and inaccessible. This makes independent testing of network infrastructures like 5G difficult for those of us who are hobbyists and enthusiasts, not associated with the major companies in the industry. So, the only way would be to start your own open-source product from scratch! It wasn't easy, as demonstrated by the price of the SignalSDR Pro shown at $1,100 for the pre-order, but independent efforts by the community like these are necessary, as sometimes, things go unnoticed even under the major innovator's scrutiny.
Kai Jern (xwings) further explained that most of the functions performed by the HAM radio can be replicated using Software Defined Radios (SDRs). So, a valid use case would be a search and rescue mission, using drones with SDRs. Furthermore, xwings also explained that if you were skilled enough to write the code for it, very technically, you could use the SDR to control Tesla vehicles as well.
This session was just a refresher for me, having already learnt some of the things during GCC in Taiwan. It was more so to do with my academic assignment, because I had wanted to conduct a Bluetooth attack.
While Bluetooth profiles are defined by the BT SIG, Kamel mentioned that the exact implementation of them is up to developers and manufacturers, which is why we see the variance in Bluetooth technologies and standards (or lack thereof).
Usage
High throughput
Short throughput
Power
High
Low
Frequency Hopping
79
40
Addressing
Public addressing (hardware)
Private addressing scheme
Discovery
Discoverable (need to pair)
Advertisement ("hi I'm here")
The BLE application cannot be mapped to the OSI layers because fundamentally, it's a technology with a very different stack. However, if it helps to visualise, Kamel had done a simple and abstracted mapping:
Application code
Application
Generic Attribute Profile (GATT)
Presentation
Attribute Profile (ATT)
Session
L2 CAP
Transport
HCI
Controller Profile
Data Link/Physical
The GATT essentially functions as a single server with many services. Each service has a unique identifier. A 16-bit identifier would be the standard as defined by the BT SIG, whereas a 32-bit identifier would be a custom/proprietary identifier. A GATT service could have 1 or more characteristics, with each characteristic of the Bluetooth service pertaining to a function like read, write, notify, and identify.
Despite the lack of attention for Bluetooth security, some efforts have been made, such as Frequency Hopping, which changes the channels of the communication to deter sniffing. There is also an invisible mode, which hides the device's address and makes it undiscoverable after it's been paired.
This was a kampung that allowed participants to try various security activities relating to RFID. The only activity I managed to attempt was closing the hotel key card. Using the proxmark3, I pulled some info from the card. One of them would be the type of card (high frequency or low frequency) and the unique identifier. Using their keychain dongle (that's actually a frequency detector), the card was determined to be high frequency. So, then the next step would be to pull the ID from the card. The card would be placed onto the PM3, then the command hf search, which will read some of the info from the card, like UID (what we want), ATQA, SAR, and card type.
Now with the UID and card type, we can use the FlipperZero, select MIFARE Classic, and enter our UID. With the FlipperZero, we can then unlock the hotel door lock.
Like Kamel's session, I've learnt some of these things before during GCC, so again, this session serves to refresh my memory.
Threat modelling is simply just a way you want to communicate threats to system stakeholders, be it management (owners/directors) or developers. How you approach them depends on who your stakeholders are; if they aren't very technical, using lower-level models with a lot of jargon would confuse your stakeholders. Likewise, developers can't do their jobs if you dumb it down and don't include the finer details.
The main models that were the focus of the session were STRIDE-LM (for less technical stakeholders) and MITRE ATT&CK (more technical), but in the real world, they use other models as well, such as PASTA, LINDDUN (privacy-focused), Attack Trees, and Persona-non-grata. You should not stick with STRIDE-LM all the way to model your threats because there are some threats that you cannot see within STRIDE-LM or that do not fit within the model. For instance, T1595.002 Vulnerability Scanning under Reconnaissance of MITRE ATT&CK doesn't really fit into any of the STRIDE definitions. You could argue and say it goes under Information Disclosure, but you get the point.
The key takeaway was the fact that there's always a glaring elephant in the room, making this job 10x harder than it has to be, and that is regarding assumptions about the system. If your developers and engineers provide a system architecture diagram that isn't holistic, then you lose a lot of the finer details between components and interactions. For instance, if a database user interacts with the database differently from the admin, how would they do so? Is it possible for them to escalate their privilege? Is it possible to move laterally across the system/network? These scopes must be clearly defined, and there can be no assumptions.
Then we moved to risk mitigation. For starters, the elimination of risks by completely avoiding the system feature is unacceptable, as it means losing the system functionality altogether. When mitigating, it's easiest to start from the highest-level view with the following:
Crown jewel
Cut across threat categories as well
Never use only one perspective to enumerate threats (ask questions!)
LLMs are often frowned upon, but Donavan mentioned that using LLMs in this case is actually good, as it can give you things that you might sometimes miss. He also mentioned that the priority changes as well depending on the application, like in the events of OT Security. The crown jewel would not be the data anymore, but rather, the process. OT doesn't care about losing data, 'cause all the attacker is getting is info such as temperature or electricity usage, etc. The crown jewel here is the process (whether they can be maintained or not).
The following session I attended was about a vulnerability within the MacBook's MagSafe. The MagSafe is Apple's coined tech for how the charger magnetically attaches to your MacBook, and there have been several iterations of the technology. MagSafe 3 (like 1 and 2) uses a 5 pin layout, 2 being for power and 2 for ground, and the remaining one for data. What sort of data you might ask? Why does a charger need to send data? Well, its for the LED indicator.
The charger's LED indicator shows the battery's level of charge. Amber is charged, and green is fully charged. However, this poses a security vulnerability because the LED is controlled using an API that is available in Apple's SDK. Instead of using the API to indicate the battery's charge, you would instead use it to send data. Doing so would see the LED blink in different modes.
You could develop a malware that leverages this API and leaks information from the computer via a side channel attack. "But how does a charger send your information to attackers?" Well, a point brought up by the speaker is the fact that people buy 3rd party accessories. If you were to buy a charger that isn't from Apple, there's a chance that within the charger itself, it has an IC that could possibly leverage this and send data despite your MacBook not sending any packets (like in the case of an air-gapped environment).
A simple way to see if you've been affected is to check if your LED indicator flashes repeatedly. A suspicious behaviour should prompt you to probe further (and it's not just the charger that is faulty).
The last session of the day (I had a flight to catch) was exploring server misconfigurations. This was an introductory workshop on black box penetration testing on an FTP server. In the exercise, the FTP port was open, and there were accounts that could be used (guest and anonymous), which allowed file transfer. You could transfer a bash payload, then execute it by fetching it from the URL.
Hardening FTP servers can be done with whitelisting certain accounts. You could also put it in jails (chroot directories to jail the account in place so they cannot escape from their root directory). Additionally, virtual users could be configured for FTP usage. Virtual users are not real system accounts and are managed by the FTP server. They are isolated from the authentication database and we can still jail them to their own root directory.
All in all, I enjoyed SINCON 2025. It was an excuse to go to Singapore and see some familiar faces. But it wasn't all just about having fun and whatnot. I was fortunate enough to get the Full Conference Pass at the behest of SherpaSec, and I got to learn new things while strengthening my knowledge on some stuff.
My only regret was not having enough time at the con because there were so many other cool things I didn't get to try. I also couldn't stay for the closing ceremony and the after party because I had a (very expensive) flight to catch for a CTF I had on the following morning :/
The journey to Singapore was also an arduous and uncertain one. My mates and I took the bus down to SG from 12 am (delayed til 1 am), but we got stuck at the border for an hour waiting for our bus :/. Not to mention arriving at 6 am, forgetting to set my debit card to bill overseas, the 7E not accepting cash, and the sudden burst of pouring rain that got us all wet. It was a journey alright (no jabs at SG. It was just our rotten bit of luck!). I did get to try Wingstop, 'cause we don't have it in MY, and it was nice. I can see the reason for the hype.
Regardless, SINCON was a great experience, and it shall remain a highlight of my 2025. Until next time!
Using the SDR, it could essentially replicate the functionality of a Base Transceiver Station (BTS), which you could also use to create rogue towers (basemans), but the point is to use the SDR to mimic the behaviours of 5G cell towers and conduct testing. Due to the nature of 5G and its infrastructure, the SDR cannot be connected to a VM or even to Windows for that matter. The SDR requires an insanely high throughput as the data rate surpasses what hypervisors (exact figures not mentioned or shown), thus, the SDR can only be used effectively when connected to a computer running Linux on bare metal. The fuzzer then runs on .
Bluetooth in itself is not a protocol, but rather a specification, which is maintained by the . Bluetooth itself has 2 main iterations, Bluetooth Classic, containing 79 channels and is used for higher bitrate devices, and Bluetooth Low Energy, containing 40 channels and is meant for lower powered devices such as IoT devices.
Crucially, to conduct any Bluetooth activities at all, one would need to procure specialised equipment (again, I wish they'd just fall out of the sky because I want one). These would include the Ellisys Bluetooth analyser (really expensive and is industry-grade testing) and the Ubertooth One (more affordable but still expensive for a student). More resources pertaining to the Bluetooth Sniffer can be found .
This was super cool to me 'cause I've never really touched anything RFID related. Having the chance to play around with gadgets and gizmos like these was something I wanted to try myself, then I heard the price of a PM3
