AI browsers introduce reasoning-based risks. Learn how cross-origin AI agents dismantle web security and what defenses are needed.
The post Convenience or Catastrophe? The Dangers of AI Browsers No One is Talking About appeared first on Security Boulevard.
The EU’s Cyber Resilience Act is reshaping global software security expectations, especially for SaaS, where shared responsibility, lifecycle security and strong identity protections are essential as attackers increasingly “log in” instead of breaking in.
The post The Cyber Resilience Act and SaaS: Why Compliance is Only Half the Battle appeared first on Security Boulevard.
AI-enabled cybercriminals are exploiting the holiday shopping season with precision phishing, account takeovers, payment skimming and ransomware, forcing retailers to adopt real-time, adaptive defenses to keep pace.
The post AI Cybercriminals Target Black Friday and Cyber Monday appeared first on Security Boulevard.
점점 더 많은 조직이 AI를 도입하면서 AI 계획과 네트워크 준비 상태 사이의 격차가 확대되고 있다. 브로드컴이 발표한 ‘2026 네트워크 운영 현황’ 보고서에 따르면, 조직의 99%가 클라우드 전략을 보유하고 AI를 도입하고 있지만, AI가 요구하는 대역폭과 낮은 지연 시간을 지원할 수 있다고 판단한 조직은 49%에 그쳤다.
또한 이번 조사에 참여한 IT 전문가 1,350명 중 95%는 특히 퍼블릭 클라우드 환경에서 네트워크 구간에 대한 가시성이 부족하다고 응답했다. 이들 응답자는 ISP로부터 더 많은 정보를 받아야 한다고 응답했다.
브로드컴 네트워크 가시성 담당 최고 기술 에반젤리스트 제레미 로스바흐는 “모두가 어떤 장비든 어떤 프로토콜이든 필요한 인사이트를 모두 확보하고 있다고 생각한다. 하지만 데이터센터 내부에서만 그렇다. 이제 모든 트래픽이 기업 데이터센터를 거쳐 움직이지 않는다. 모두 퍼블릭 네트워크를 사용한다”라고 지적했다. 로스바흐는 “데이터센터 외부까지 가시성을 확장하는 흐름이 빠르게 확산되고 있고, 결국 더 많은 데이터를 수집해야 한다는 의미다. 데이터가 많을수록 네트워크 운영 수준이 높아진다”라고 설명했다.
응답자의 87%는 인터넷과 클라우드 환경이 여러 영역에서 네트워크 사각지대를 만든다고 답했다. 조직의 절반은 퍼블릭 클라우드에 대한 인사이트가 부족하다고 답했고, 44%는 전송망과 피어링 네트워크가 사각지대를 만든다고 응답했다. 43%는 원격근무 환경의 가시성이 부족하다고 답했다. 가시성 문제를 유발하는 다른 영역은 프라이빗 클라우드(39%), ISP 라스트마일(38%), 온프레미스 근무 환경(30%)이었다.
가시성 문제는 ISP와의 관계에도 영향을 미쳤다. 네트워크 운영팀의 5%만이 ISP로부터 필요한 정보를 모두 받고 있다고 답했다. 대부분 응답자는 DNS 문제(50%), 경로 지연(49%), 경로별 과거 성능 데이터(45%), DDoS 공격 위치(45%), 노드 또는 홉 문제(44%), 패킷 손실(43%) 데이터를 요구했다. 가시성이 부족하면 운영 효율성에 직접적인 영향을 미치기 때문이다. 응답자는 가시성이 네트워크 전달 문제 분석(56%), 경로 변경 영향 파악(49%), 용량 문제 예측(48%), 사용자 경험 추적(48%)에 필수적이라고 답했다.
로스바흐는 “구글 클라우드가 어떤 AI 이니셔티브의 일부를 호스팅하고 있는데 해당 네트워크를 볼 수 없다면, 민원을 제기한 사용자의 네트워크 경로를 어떻게 진단할 수 있겠는가? 더 이상 그런 블랙홀을 허용할 수 없다”라고 말했다.
가시성 문제는 네트워크 운영에도 영향을 미쳤다. 응답자는 가시성이 전달 문제 분석(56%), 경로 변경 영향 파악(49%), 용량 문제 예측(48%), 사용자 경험 추적(48%)에 필수적이라고 답했다.
AI 도입 계획과 네트워크 준비도 사이의 괴리가 네트워크 운영에 여러 문제를 만들고 있다. 설문 응답자는 AI 성공에 영향을 주는 요인으로 다음을 지목했다.
로스바흐는 “네트워크 운영 관점에서 AI를 도입하는 방법은 마차보다 말이 앞서지 않도록 하는 것이다. 많은 조직이 ‘AI를 도입하자’고 말하지만, 정작 마차에는 바퀴가 세 개뿐이다. 네 번째 바퀴를 먼저 달아야 한다. 그 네 번째 바퀴가 네트워크 옵저버빌리티 역량이다”라고 강조했다.
dl-ciokorea@foundryco.com
Enterprise GenAI success depends on more than models—security, observability, evaluation, and integration are critical to move from fragile pilots to reliable, scalable AI.
The post Securing GenAI in Enterprises: Lessons from the Field appeared first on Security Boulevard.
Welcome back aspiring hackers!
In this chapter, we’re going deeper into the ways defenders can spot you and the traps they set to catch you off guard. We’re talking about defensive mechanisms and key Windows Event IDs that can make your life harder if you’re not careful. Every hacker knows that understanding defenders’ tools and habits is half the battle.
No system is perfect, and no company has unlimited resources. Every growing organization needs analysts constantly tuning alerts and security triggers as new software and users are added to the network. It’s tedious and repetitive work. Too many alerts can exhaust even the sharpest defenders. Eye fatigue, late nights, and false positives all drain attention. That’s where you get a small window to make a move, or a chance to slip through unnoticed.
Assuming nobody is watching is a beginner’s mistake. We’ve seen many beginners lose access to entire networks simply because they underestimated defensive mechanisms. The more professional you become, the less reckless you are, and the sharper your actions become. Always evaluate your environment before acting.
Defenders have a few main ways they can detect you, and knowing these is crucial if you want to survive:
Process monitoring allows defenders to keep an eye on what programs start, stop, or interact with each other. Every process, PowerShell included, leaves traces of its origin (parent) and its children. Analysts use this lineage to spot unusual activity.
For example, a PowerShell process launched by a Microsoft Word document might be suspicious. Security teams use Endpoint Detection and Response (EDR) tools to gather this data, and some providers, like Red Canary, correlate it with other events to find malicious patterns.
Command monitoring focuses on what commands are being run inside the process. For PowerShell, this means watching for specific cmdlets, parameters, or encoded commands. Alone, a command might look innocent, but in combination with process monitoring and network telemetry, it can be a strong indicator of compromise.
Attackers often use PowerShell to download tools or exfiltrate data over the network. Monitoring outgoing and incoming connections is a reliable way for defenders to catch malicious activity. A common example is an Invoke-Expression command that pulls content from an external server via HTTP.
Let’s break down the logs defenders rely on to catch PowerShell activity:
AMSI stands for Antimalware Scan Interface. Think of it as a security checkpoint inside Windows that watches scripts running in memory, including PowerShell, VBScript, and WMI.
AMSI doesn’t store logs in the standard Event Viewer. Instead, it works with Event Tracing for Windows (ETW), a lower-level logging system. If you bypass AMSI, you can execute code that normally would trigger antivirus scans, like dumping LSASS or running malware, without immediate detection.
But AMSI bypasses are risky. They’re often logged themselves, and Microsoft actively patches them. Publicly available bypasses are a trap for anyone trying to survive quietly.
ScriptBlock logging watches the actual code executed in PowerShell scripts. There are two levels:
Automatic (default): Logs script code that looks suspicious, based on Microsoft’s list of dangerous cmdlets and .NET APIs.
Global: Logs everything with no filters.
Event ID 4104 collects this information. You can bypass this by downgrading PowerShell to version 2, if it exists, but even that downgrade can be logged. Subtle obfuscation is necessary. Here is how you downgrade:
PS > powershell -version 2
Note, that ScriptBlock logging only works with PowerShell 5 and above.
Even older PowerShell versions have Event ID 400, which logs when a PowerShell process starts. It doesn’t show full commands, but the fact that a process started is noted.
Module logging (Event ID 800) tracks which PowerShell modules are loaded, including the source code for commands run via Add-Type. This is important because Add-Type is used to compile and run C# code.
In PowerShell 5+, Event ID 4103 also logs this context. If a defender sees unusual or rarely-used modules being loaded, it’s a red flag.
Sysmon is a specialized Windows tool that gives defenders extra visibility. Usually defenders monitor tracks:
Event ID 1: Every new process creation.
Event ID 7: Module loads, specifically DLLs.
Event ID 10: Process Access, for instance accessing lsass.exe to dump credentials.
For PowerShell, Event ID 7 can flag loads of System.Management.Automation.dll or related modules, which is often a clear indicator of PowerShell use. Many other Sysmon IDs might be monitored, make sure you spend some time to learn about some of them.
To check if Sysmon is running:
PS > Get-Service -Name sysmon
To view recent Sysmon events:
PS > Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvent 20 | Format-List TimeCreated, Id, Message
Not all systems have Sysmon, but where it’s installed, defenders trust it. Essentially, it is like a high-tech security camera that is detailed, persistent, and hard to fool.
EDR tools combine all the telemetry above such as processes, commands, modules, network traffic to give defenders a full picture of activity. If you’re working on a system with EDR, every move is being watched in multiple ways.
Attackers are predictable. If you run the same commands repeatedly, defenders notice. Red Canary publishes filters that show suspicious PowerShell activity. Not every system uses these filters, but they’re widely known.
Using -encodedcommand or Base64 can trigger alerts. Base64 itself isn’t suspicious, but repeated or unusual use is a warning sign.
Adding extra characters (^, +, $, %) can throw off detection, but too much is suspicious.
Some cmdlets are commonly abused. These include ones for downloading files, running scripts, or managing processes. Knowing which ones are flagged helps you avoid careless mistakes.
Scripts running from odd locations, like Public folders, are more likely to be flagged. Stick to expected directories or in-memory execution.
Even when your movement is restricted, options exist.
1) Use native binaries. Legitimate Windows programs are less suspicious.
2) Less common commands. Avoid widely abused cmdlets to reduce detection.
3) Living-Off-the-Land. Using built-in tools creatively keeps you under the radar.
We’ll cover these in more depth in the next chapter, how commands meant for one thing can be adapted for another while remaining invisible.
The net command is powerful, but can be monitored. Use net1 to bypass some filters in really strict environments:
PS > net1 user
This lets you run the full suite of net commands quietly.
Deleting logs can sometimes be a good idea, but you should know that Event ID 1102 flags it immediately. Also, even less experienced defenders can trace lateral movement from log records. Traffic spikes or SMB scans are noticed quickly.
Focus on minimizing your footprint and risk. High-risk, complex techniques are not part of this guide.
Files on disk can betray your tactics. If saving is necessary, use native-looking names, unusual folders, and adjust timestamps. Stick to in-memory execution where possible. Lesser-known commands like odbconf.exe and cmstp.exe are safer and often overlooked. Use them for execution.
Downgrading can bypass ScriptBlock logging. But you need to obfuscate things carefully. Subtlety is key here.
Tweaking log collectors can buy time but is riskier. Always revert these changes after finishing. It’s always good to have a backup of the config files.
Use known credentials rather than brute-forcing. Work during normal hours to blend in well and dump traffic to understand local activity. Using promiscuous mode can help you get richer network insights. Targeting common ports for file distribution is also a good idea and blends in well with normal traffic patterns.
In this part we learned more about the enemy and how defenders see your every move. We broke down the main ways attackers get caught, such as process monitoring, command monitoring and network monitoring. From there, we explored Windows Event IDs and logging mechanisms. We emphasized survival strategies that help you minimize footprint by using in-memory execution, sticking to lesser-known or native commands, using version 2 PowerShell or blending in with normal traffic. Practical tips like the net1 trick and log handling process give you an idea how to avoid raising alarms.
When you understand how defenders observe, log, and respond it lets you operate without tripping alerts. By knowing what’s watched and how, you can plan your moves more safely and survive longer. Our goal here was to show you the challenges you’ll face on Windows systems in restricted environments and give you a real sense that you’re never truly alone.
The post PowerShell for Hackers-Survival Edition, Part 3: Know Your Enemy first appeared on Hackers Arise.
The AI Governance Tightrope: Enabling Innovation Without Compromising Security Cybersecurity leaders are facing a critical inflection point. The rapid emergence of artificial intelligence technologies presents both unprecedented opportunities and significant...
The post Innovator Spotlight: Singulr AI appeared first on Cyber Defense Magazine.
Welcome back, my aspiring cyberwarriors!
Every few minutes an airplane may fly over your head, maybe more than one. If you live close to an airport, the air traffic in your area is especially heavy. Services like Flightradar24 show information about aircraft in the air with surprising accuracy because they get data using the ADS-B protocol. You can collect that data yourself, and here we will show how.
Of course, everyone has flown on a plane or at least seen one. These large metal birds circle the globe and carry hundreds of millions of people to different parts of the world. That wasn’t always the case. Just 100 years ago people mostly moved by land and there were no highly reliable flying machines. After planes were invented and commercial flights began, it became clear that we needed a way to track aircraft in the sky, otherwise accidents would be unavoidable. Radar and visual observation are not enough for this, so radio communication came into use. Now every aircraft has an aviation transponder on board. It makes life much easier for dispatchers and pilots, as the aircraft sends data from onboard sensors and receives instructions from the ground while in flight.
Put simply, an aviation transponder is a two-way radio device that does two things:
1. Answers queries from ground stations: when an air traffic controller requests data, the transponder replies automatically. A query for data is also called interrogation.
2. Acts as an airborne radio beacon: in this mode the transponder periodically broadcasts information about itself, for example position or speed.
There are different generations or modes of transponders. Each was created for different purposes and has its own signal structure. Although newer modes keep the features of the older ones, the signal protocols are not mutually compatible. There are five main modes:
1. Mode A: transmits only the aircraft’s identification code. This code can be hard-programmed into the transponder or assigned by the dispatcher before flight. In practice Mode A was mostly used to track which aircraft was at which airport.
2. Mode C: developed later, it allowed tracking not only the aircraft ID but also flight altitude. Its main advantage was that altitude could be obtained automatically without asking the pilot.
3. Mode S: this is the modern mode used on about 99% of all aircraft today. It allows not only reading sensor data from the aircraft but also sending data back to the plane. In Mode S an aircraft has full two-way communication with ground stations. ADS-B, which we will look at today, is part of this mode.
4. Mode 4 and Mode 5: these are more advanced but used only by the military. Both are much better protected (that is, they have some security, unlike the older modes), so they are not something we can play with.
A careful reader will notice we did not include Mode B or Mode D in the list. Both existed only briefly, so it makes little sense to discuss them here.
If you read the description of Mode S closely, you’ll notice that Mode S messages are normally sent by the transponder in response to a ground station query. All of them except ADS-B. ADS-B stands for Automatic Dependent Surveillance Broadcast. In plain English that means it is an automatic flight-tracking system. The word “Broadcast” means the messages are sent out to everyone, not to a specific recipient, and that lets us receive them.
Many people treat ADS-B as a separate transponder mode on the same level as Mode A, C, or S, but actually ADS-B is just a part of Mode S. An ADS-B message is simply a Mode S message with type 17.
We will focus on ADS-B (type 17) in this article, but it helps to know about other Mode S message types for context:
All-call reply (type 11): the transponder replies to a ground interrogation with a unique 24-bit identifier. This number is usually programmed at the factory and does not change, although in military contexts it may be altered.
ACAS short and long replies (type 0/16): messages used by collision-avoidance systems. If a transponder detects another aircraft nearby it will send alerts to other systems that can prevent a mid-air collision.
Altitude and identity replies (type 4/5): messages containing altitude and the call sign (the so-called squawk code that the pilot enters before flight).
Comm-B (type 20/21): messages with readings from onboard sensors, planned route, and other data useful for aircraft control.
ACAS is especially clever in how it works, but discussing it in detail would take us beyond this article.
All Mode S transmissions to aircraft use 1030 MHz (uplink), and transmissions from aircraft to the ground use 1090 MHz.
The radio transmission itself is not encrypted. It carries a lot of useful information about the aircraft’s position, altitude, speed, and other parameters. That is how services like Flightradar24 started making aircraft information available to everyone for free. These services collect data from many sensors installed by volunteers around the world. You can become one of those volunteers too. All you need is to sign up and get a receiver from a service operator for installation.
ADS-B signals are transmitted by aircraft on 1090 MHz, just like the other Mode S signals. The other frequency, 1030 MHz (uplink), is not needed for ADS-B because ADS-B transmissions are sent without being asked.
Pulse-Position Modulation (PPM) is used to encode the signal. In basic terms, the transmitter sends bits over the air that can be read by sampling the signal every N microseconds. On ADS-B each bit lasts 0.5 microseconds, so you can sample every 0.5 μs, see whether the signal level is high or low at each moment, record that, then convert the result into bytes to reconstruct the original message. That’s the theory, in practice it’s more challenging.
If you take the raw sampled data you first get a bit of a mess that must be parsed to extract useful information. The messages themselves have a clear structure, so if you can find repeated parts in the data stream you can reconstruct the whole packet. A packet consists of a preamble and the data payload. The preamble lasts 8 μs, and then the data follows for either 56 or 112 μs.
The preamble is especially important because all aircraft transmit on the same frequency and their signals can arrive at the receiver at the same time. Loss of overlapping signals is handled simply: if a receiver fails to catch a message, some other receiver will. There are many receivers and they cover all inhabited land on Earth, so if a particular signal is too weak for one receiver it will be loud enough for another. This approach doesn’t guarantee every single signal will be caught, but ADS-B messages are transmitted repeatedly, so losing some packets is not a disaster.
We already said each bit is encoded as 0.5 μs, but to make reception easier a convention was introduced where one real bit is encoded using two half-microsecond elements. A logical one is encoded as “1 then 0”, and a logical zero as “0 then 1”. For example, data bits 1011 would be transmitted as 10011010. This does not complicate the receiver much, but it protects against noise and makes the signal more reliable. Without this doubling, a sequence of zeros would look like silence. With it the receiver always detects activity, even when zeros are sent.
Suppose we decoded the signal and found a message. Now we need to decode the payload and filter out unwanted messages (that is, all Mode S messages except ADS-B).
The ADS-B message length we care about is 112 μs, which corresponds to 112 bits (thanks to the two-half-microsecond coding!). The message divides into five main blocks:
1. DF (Downlink Format) – the format code, 5 bits. For ADS-B this is always 17.
2. CA (Transponder capability) – type of transponder and its capability level, 3 bits. This tells a controller what data can be requested from this transponder. This field can be 0, 4, 5, or 6. Values 1–3 and 7 are reserved for future use. 0 means a first-level transponder, usually without ACAS. 4 means a second-level (or higher) transponder that can send altitude (i.e., supports Mode C and Mode S) but does not have ACAS. 5 and 6 are like 4 but with ACAS support: 6 indicates ACAS may be enabled, 5 indicates ACAS may be present but disabled.
3. ICAO — unique aircraft number, 24 bits. This number identifies the signal sender. It is typically programmed once at the factory and does not change during operation, although some people know how to change it. Military transponders follow different rules, so anything can happen there.
4. ME (Message) – the actual payload with data about altitude, speed, or other information. Length is 56 bits. We will look at this block in detail below.
5. PI (Parity/Interrogator ID) – checksum, 24 bits.
The ME field is the most interesting part for us because it carries coordinates, speed, altitude, and other data from onboard sensors. Since 56 bits are not enough to carry all possible data at once, each message has a type indicated by the first five bits of ME. In other words, there is a nested format: Mode S uses a certain message type to indicate ADS-B, and ADS-B uses its own internal type to say what data is inside.
ADS-B defines 31 data types in total, but we will review only the main ones.
Type 1-4: identification messages. They contain the call sign and other registration/identification information (for example, whether this is a light aircraft or a heavy one). These call signs are shown on airport displays and usually reflect the flight number. A decoded message looks approximately like this:
Type 5-8: ground position. These messages are used to know where and on which runway the aircraft is located. The message may include latitude, longitude, speed, and heading. Example decoded message:
Type 9-19: airborne position (usually transmitted together with altitude). It is important to understand that you will not always find latitude and longitude in the usual long numeric form in these messages, instead a compact notation is used.
Type 19: aircraft velocity.
We could go bit-by-bit through the structure of each message, but that takes a long time. If you are really interested you can find ready ADS-B parsers on GitHub and inspect the formats there. For our purpose, however, diving deeper into the protocol’s details isn’t necessary right now, because we are not going to transmit anything yet.
To describe a location, we usually use latitude and longitude. A 32-bit floating number can store them with about seven decimal places, which is accurate down to a few centimeters. If we don’t need that much detail and are fine with accuracy of just tens of centimeters, both latitude and longitude together could be stored in about 56 bits. That would have been enough, and there would be no need for special “compressed” coordinate tricks. Since an airplane moves at more than 100 meters per second, centimeter-level accuracy is useless anyway. This makes it strange why the protocol designers still chose the compact method.
CPR (Compact Position Reporting) is designed specifically to send coordinates compactly. Part of CPR was already visible in the coordinate example earlier. Because it’s impossible to compress a lot of data into a small field without loss, the designers split the data into parts and send them in two passes with packets labeled “even” and “odd”. How do we recover normal coordinates from this? We will show the idea.
Imagine all aircraft flying in a 2D plane. Divide that plane into two different grids and call them the even grid and the odd grid. Make the even grid 4×4 and the odd grid 5×5. Suppose we want to transmit a position that in a 16×16 grid is at (9, 7). If we had one grid we would just send 9 and 7 and an operator could locate us on the map. In CPR there are two grids, though.
In these grids we would represent our position (9, 7) as (1, 3) on the even grid and (4, 2) on the odd grid. When an operator receives both messages, they must align the two grids.
If you overlay the grids with the received coordinates, the point of intersection is the true location.
We described the algorithm without math so you can imagine how coordinates are reconstructed from two parts. The real grids are far more complex than our toy example and look like the image below.
Now that we understand the main parts of the protocol, we can try to receive a real signal. To receive any such signal you need three basic things: an antenna, a receiver, and a PC.
Start with the most important item, which is the antenna. The choice depends on many factors, including frequency, directionality of the signal, and the environment where it travels. Our signal is transmitted at 1090 MHz, and we will receive it outdoors. The simplest antenna (but not the most efficient) is a straight rod (a monopole). You can make such an antenna from a piece of wire. The main thing is to calculate the right length. Antenna length depends on the wavelength of the signal you want to receive. Wavelength is the distance between two neighboring “peaks” of the wave.
Lambda (λ) is the wavelength. You get it from frequency with the formula λ = C / f, where C is the speed of light and f is the signal frequency. For 1090 MHz it is about 27.5 cm. If you take a metal rod of that length you get a full-wave antenna, which you can safely shorten by half or by four to get a half-wave or quarter-wave antenna, respectively. These different designs have different sensitivity, so I recommend a half-wave antenna, which should be roughly 13.75 cm long.
We won’t build our own antenna here. It is not the simplest task and we already had a suitable antenna. You might use radio handheld antennas if you receive outdoors and there isn’t too much interference. We use a simple vertical coil-loaded whip antenna. It behaves like a whip but is shorter because of the coil.
You can measure antenna characteristics with a special vector network analyzer that generates different frequencies and checks how the antenna reacts.
The output from NanoVNA looks complicated at first, but it’s simple to interpret. To know if an antenna suits a particular frequency, look at the yellow SWR line. SWR stands for standing wave ratio. This shows what part of the signal the antenna radiates into the air and what part returns. The less signal that returns, the better the antenna works at that frequency. On the device we set marker 1 to 1090 MHz and SWR there was 1.73, which is quite good. Typically an antenna is considered good if SWR is about 1 (and not more than 2).
For the receiver we will use an SDR dongle. It’s basically a radio controlled by software rather than a mechanical dial like old receivers. Any SDR adapter will work for ADS-B reception, from the cheap RTL-SDR to expensive devices like BladeRF. Cheap options start around $30, so anyone can get involved. We will use a BladeRF micro, as it supports a wide frequency range and a high sampling rate.
Once you have an antenna and an SDR, find a place with few obstructions and low interference. We simply drove about ten kilometers out of town. Signals near 1 GHz (which includes ADS-B) don’t travel much past the horizon, so if you don’t live near an airport and there are obstacles around you may not catch anything.
To inspect the radio spectrum we use GQRX. This program is available for Linux and macOS. On Windows we recommend SDR#. In Ubuntu GQRX can be installed from the standard repositories:
bash$ > sudo apt update
bash$ > sudo apt install -y gqrx
Then increase the volume, select your SDR as the input source, and press the large Start button. If everything is set up correctly, your speakers will start hissing loudly enough to make you jump, after which you can mute the sound with the Mute button in the lower right corner.
You can choose the receive frequency at the top of the screen, so set it to 1.090.000, which equals 1090 MHz. After that you will see something like the screenshot below.
The short vertical strips near the center are ADS-B signals, which stand out from the background noise. If you don’t see them, try changing the gain settings on the Input Controls tab on the right. If that does not help, open FFT Settings and adjust the Plot and WF parameters. You can also try rotating the antenna or placing it in different orientations.
When you get stable reception in GQRX you can move to the next step.
In practice, people who want to receive and decode Mode S signals usually use an existing program. A common open-source tool demodulates and decodes almost all Mode S signals and even outputs them in a neat table. To verify that our setup works correctly, it’s best to start with something that’s known to work, which is dump1090.
To install it, clone the repository from GitHub and build the binary. It’s very simple:
bash$ > git clone https://github.com/antirez/dump1090
bash$ > cd dump1090
bash$ > make
After that you should have the binary. If you have an RTL-SDR you can use dump1090 directly with it, but we have a BladeRF which requires a bit more work for support.
First, install the driver for your SDR. Drivers are available in the repositories of most distributions, just search for them. Second, you will need to flash special firmware onto the SDR. For BladeRF those firmware files are available on the Nuand website. Choose the file that matches your BladeRF version.
Next, download and build the decoding program for your SDR:
git clone https://github.com/Nuand/bladeRF-adsb
cd bladeRF-adsb/bladeRF_adsb
make
Then flash the firmware into the BladeRF. You can do this with the bladerf-cli package:
bash$ > bladeRF-cli -l ~/Downloads/adsbxA4.rbf
Now run dump1090 in one terminal and bladeRF-adsb in another (the commands below are examples from our setup):
bash$ > ~/Soft/dump1090/dump1090 --raw --device-type bladerf --bladerf-fpga ' '
bash$ > ~/Soft/Blade/bladeRF-adsb
If everything is correct, in the dump1090 window you will see many hexadecimal lines, those are Mode S messages that still need to be decoded and filtered.
If you remove --raw from the dump1090 startup arguments, the program will automatically decode messages and display them in a table.
Now you’ve seen how aircraft transponders work, what ADS-B actually is, and how signals at 1090 MHz can be received and decoded with simple equipment. None of this requires expensive tools, just an antenna, a software-defined radio and some patience. Once it’s ready, you can watch the same kind of live flight data that powers big services like Flightradar24. We kept the heavy math out of the way so it stays approachable for everyone, but still leaves you with something useful to take away. It’s possible to push yourself further and do it the hard way without relying on tools like dump1090, but that path takes a lot more time, patience, and willingness to grind through the details.
The post SDR (Signals Intelligence) for Hackers: Capturing Aircraft Signals first appeared on Hackers Arise.
Varun Uppal, founder and CEO of Shinobi Security Over the weekend, airports across Europe were thrown into chaos after a cyber-attack on one of their technology suppliers rippled through airline...
The post When Airports Go Dark: What The Weekend’s Cyber-attacks Tell Us About Business Risk appeared first on Cyber Defense Magazine.
The Invisible Threat: Reimagining Third-Party Risk Management Cybersecurity leaders are drowning in questionnaires while threat actors are swimming in data. The traditional approach to vendor risk management is broken, and...
The post Innovator Spotlight: Black Kite appeared first on Cyber Defense Magazine.
LastPass Evolves Secure Access Experiences to Combat Shadow IT and AI Risks for CISOs Picture your organization humming along, with teams adopting new apps to boost efficiency. But beneath that...
The post Innovator Spotlight: LastPass appeared first on Cyber Defense Magazine.
The Network’s Hidden Battlefield: Rethinking Cybersecurity Defense Modern cyber threats are no longer knocking at the perimeter – they’re already inside. The traditional security paradigm has fundamentally shifted, and CISOs...
The post Innovator Spotlight: Corelight appeared first on Cyber Defense Magazine.
Zero Trust: The Unsung Hero of Cybersecurity Cybersecurity professionals are drowning in complexity. Acronyms fly like digital confetti, vendors promise silver bullets, and CISOs find themselves perpetually playing catch-up with...
The post Innovator Spotlight: OPSWAT appeared first on Cyber Defense Magazine.
Last Updated on December 2, 2025 by Narendra Sahoo
Getting PCI DSS compliant is like preparing for a big exam. You cannot just walk into it blind, you first need to prepare, check your weak areas, next fix them, and then only face the audit. If you are here today for the roadmap, I assume you are preparing for an audit now or sometime in the future, and I hope this PCI DSS 4.0 Readiness Roadmap helps you as your preparation guide. So, let’s get started!
The first mistake many companies make is they don’t know what is really in the PCI scope. So, start with an inventory.
This is one area where many organizations rely on pci dss compliance consultants to help them correctly identify what truly falls under cardholder data scope.
Write all this down in a spreadsheet. Mark which ones store, process, or transmit card data. This becomes your “scope map.”
Now take the PCI DSS 4.0 standard and see what applies to you. Some basics:
Example: If you’re running an e-commerce store on Magento and it connects to MySQL, check if your DB is encrypted and whether DB access logs are kept.
Real story: A retailer I advised had their POS terminals still running Windows XP. They were shocked when I said PCI won’t even allow XP as it’s unsupported.
PCI DSS is not just about tech. If your staff doesn’t know, they’ll break controls.
Example: A company using Zendesk for support had to train agents not to ask customers for card details over chat or email.
Auditors don’t just look for controls, they look for evidence.
Example: If you are using AWS, enable CloudTrail + GuardDuty to continuously monitor activity.
Before the official audit, test yourself.
Example: I’ve seen companies that have everything in place but fail because their staff can’t explain what’s implemented.
Finally, once you have covered all major gaps, bring in a QSA (like us at VISTA InfoSec). A QSA will validate and certify your compliance. But if you follow the above steps, the audit becomes smooth and you can avoid surprises.
We recently helped Vodafone Idea achieve PCI DSS 4.0 certification for their retail stores and payment channels. This was a large-scale environment, yet with the right PCI DSS 4.0 Readiness Roadmap (like the one above), compliance was achieved smoothly.
Remember, even the largest organizations can achieve PCI DSS 4.0 compliance if they start early, follow the roadmap step by step, and keep it practical.
Most businesses panic only when the audit date gets close. But PCI DSS doesn’t work that way. If you wait till then, it’s already too late.
So, start now. Even small steps today (like training your staff or fixing one gap) move you closer to compliance.
For more than 20 years, we at VISTA InfoSec have been helping businesses across fintech, telecom, cloud service providers, retail, and payment gateways achieve and maintain PCI DSS compliance. Our team of Qualified Security Assessors (QSAs) and technical experts works with companies of every size, whether it’s a start-up launching its first payment app or a large enterprise.
So, don’t wait! Book a free PCI DSS strategy call today to discuss your roadmap. You may also book a free one-time consultation with our qualified QSA.
The post PCI DSS 4.0 Readiness Roadmap: A Complete Audit Strategy for 2025 appeared first on Information Security Consulting Company - VISTA InfoSec.
Securing the Browser’s Blind Spot By Victoria Hargrove, CDM Reporter What CSide Does Most security stacks fortify servers, databases, and internal apps. CSide (Client-side Development, Inc. aka c/side) targets the...
The post Innovator Spotlight: CSide appeared first on Cyber Defense Magazine.
I will start the new year with a simple entry. Specifically, monitoring my own services. As time goes by and you have more and more websites or servers that like to stop working from time to time for various reasons, it is worth monitoring their status. Especially when they are sites or services that provide a cash flow. However, whatever the
With every webpage loaded, email sent, or video streamed, network traffic takes a complex journey across multiple infrastructure nodes. From the device to the destination, data packets travel across various gateways, networks, through routers, switches, and service providers along the way. Understanding the network traffic paths and segments along the journey reveals much about performance,…
The post Understanding Network Traffic Flow and Segment Analysis appeared first on Exoprise.
Login