How to create an EVIL LTE Twin

Adam Toscher
5 min readJun 5, 2019


Be very careful when playing with any cellular bands. Denial of service attacks can have devastating and sometimes jail worthy consequences. All testing was done within a Faraday Cage.

The cellular world is cryptic and confusing. Although we’re constantly engrossed in our phones, or tied to some device talking to some “eNodeB” — the back end cellular infrastructure is different and a relic of the telecom industry’s golden age. When I tried to research LTE, I would often fall into a Google search abyss loop to only self realize, this information needed to be curated. There was too much redundancy and not enough clarity, cellular attacks and techniques were everywhere but hard to find.

I found myself constantly reading academic articles and listening to really intelligent people at conferences.

I’d come home to my SDR’s — my expensive toys — but felt helpless and frustrated with specific firmware versions and even tougher software to troubleshot when building an evil twin.

I wanted to lessen the blow on the community as a whole, and fix some of the bugs collectively, so we don’t feel the growing pains as cellular networks become more intertwined in daily infrastructure and security related tasks.

I had a problem — how do we hack the cell towerz? So I sought a solution. I curated sources of information, dug through forums and tested software and hardware myself. I made a blog to condense that information.

I read a lot. The recent traction that the 360 Team was making waves in the last few weeks of May 2019 rekindled my curiosity.

I began the process, with the intentions of sharing the information, and testing both hardware and software. Below are some guides I used when installing and testing hardware/software combinations for LTE Evil Twinning.

srsLTE Install

# sudo apt-get install cmake libfftw3-dev libmbedtls-dev libboost-program-options-dev libconfig++-dev libsctp-dev# sudo add-apt-repository ppa:bladerf/bladerf
# sudo apt-get update
# sudo apt-get install bladerf
#apt-get install libsctp-dev lksctp-tools# git clone
# cd srsLTE
# mkdir build
# cd build
#cmake ../
# make
# make test

Installing drivers for the USRP B200mini is a painless process and for a portable entry level UHD device — I could easily swap the UHD from machine to machine and download the firmware directly from their own tool kit. This makes dealing with the Blade-RF devices firmware a hassle comparatively.

git clone git://
cd gr-osmosdr/
mkdir build
cd build/
cmake ../
sudo make install
sudo ldconfig
apt-get install libuhd-dev libuhd003 uhd-host
* First probe for the UHD device, then run the UHD firmware software if you have any issues running srsenb/srsue *
A happy srsLTE configuration, ready to compile

srsLTE/OpenLTE issues

  • PolarSSL no longer supported on latest Debian
  • Install all the correct dependencies
  • Ensure you’re using the right version of OpenLTE
  • If you get a lot of “LOLLLLLOOOL” errors when launching your software based enodeB, its due to to clock speed and the delicate timing nature of cellular communications
  • Ideally use bare metal, (Intel/AMD processors) if possible to avoid performance issues
  • Antennas do matter

LTE Evil Twin

When you launch srsue, this uses a “radio”. When you execute “srsenb” this uses a “radio”. You need two computers, and two radios to create a working LTE network that is fully functional. If you want a “Test” network, then you can use one USRP and one machine, though it’s not fully intended behavior by the software.

Please be responsible and careful. You can use your LTE network — nefariously; from jamming particular bands, to obtaining sensitive information from devices such as the IMSI number.

The one piece of information I couldn’t find anywhere? - Yes!!! — You can run an Evil Twin, and use one virtual PC image with a USRP b200-mini .

Note — The only way to create a somewhat reliable USB based LTE network is with a USRP UHD based device (NOT A HackRF) from my cursory testing.

For research reasons, I was trying to man-in-the middle specific devices that connect to the largest cellular network in the USA. Test devices were on a test network, that were disclosing their IMSI, and trying to connect to the faux network when conditions were met.

IMSI number from test device above

Using this method I was able to do obtain the IMSI devices using an LTE Evil Twin from my own lab and equipment. Be careful, and always be responsible with cellular infrastructure. Ensure you’re testing within a Faraday cage, and not causing any interference or violating any FCC laws.

Follow me @W00tock



Adam Toscher

Adam is a offensive security engineer and red team operator with over 20 years of experience in IT