When I heard about the Citrix NetScaler vulnerability (CVE-2019-19781) I wanted to capture some exploits to see what they were doing. It turns out Citrix provide a downloadable version of Citrix Gateway (which was also vulnerable), but using it to capture exploits turned out to be trickier than I’d originally anticipated.
Continue ReadingI’ve decided that it’s time to launch Life 2.0 and actually get serious about my career and put more effort in to achieving some of my other goals.
I’ve been interested in reverse engineering malware since I taught myself 8086/8088 assembly language and bought what was probably my first I.T. book — The New Peter Norton Programmer’s Guide to The IBM PC & PS/2 (by Peter Norton and Richard Wilton, 2nd edition (C) 1988) — because it documented the ROM BIOS software interrupts that the Stoned virus was using. The book had an appendix at the end to talk about MS-DOS v4.0!
The Stoned virus had infected some of the school computers, but it was reasonably benign (it would occasionally print something along the lines of ‘Your PC is now stoned’ instead of booting) and I was curious as to what made it tick and how it spread.
I later had the pleasure of coming across the Michelangelo virus, which also infected some of the school computers, but it had more sinister motives. The Michelangelo virus used BIOS interrupt 0x1a to read the date from the real-time clock (it was checking for the 06th March), but it had a bug in that it didn’t actually check if the call succeeded. On the 06th March, it would start formatting hard disk sectors.
After discovering that these (boot block/MBR) viruses were spreading by ‘hooking’ BIOS interrupt 0x13 (disk services) — installing their own interrupt 0x13 handler which would infect the boot block of the disk being accessed before passing control to the real BIOS interrupt 0x13 handler — I developed some boot code of my own.
My boot code simply stored a copy of the original (clean) interrupt vectors (a table that specified the memory addresses of the various interrupt handlers) on disk, and checked it against the memory copy of the interrupt vectors. If a boot block virus was resident and hooking interrupts, my boot code would detect the modified interrupt vectors, restore them (so that the memory resident virus would no longer get control), and copy itself back to the MBR (Master Boot Record), thus cleaning the disk.
This was all nice and dandy, except it wouldn’t have worked if the virus knew of my boot code, as it would have been too easy to check for it and skip it, so it was a good theoretical exercise that wouldn’t have worked in practice (or not for long anyway).
I then came across file infecting viruses which, unlike most of today’s malware, would actually write their own code in to an existing executable file (usually .com files because there were more of them back then, and it was harder to modify a .exe file because of its headers and what not). File infecting viruses also used interrupt hooking, only with MS-DOS’ interrupt 0x21.
This curiosity and interest in viruses then naturally lead to an interest in #DFIR (Digital Forensics and Incident Response) — a way of keeping the mind busy by determining how viruses and malware managed to infect a system, and what they did once they had — but being employed as a UNIX system administrator wasn’t exactly allowing me to do much in the way of forensics/reverse engineering work, especially of Windows binaries!
That’s when I started doing forensics/reverse engineering as a ‘hobby’ by deliberately dangling a poor defenceless MS-Windows box out on an unprotected Internet link to see what happened. I’d wait for it to get infected (which generally didn’t take long back then), and then examine the system, any malicious files, and the network packets (to learn how shellcode — short snippet of code originally designed to start a shell on the target host — worked).
Things were progressing slowly, as I still had my UNIX admin day-job, so needless to say I jumped at a chance to use some credit my then employer had with SANS, by doing the SANS 508: Computer Forensics, Investigation, and Response (as it was back then).
Things still progressed slowly, as I wasn’t getting much time to do #DFIR work other than at home as a hobby, until, that is, I ended up resigning from my job so that I could head overseas to see a terminally ill relative who hadn’t been given much longer to live.
Upon returning from the trip, I was jobless. This was good though, as I suddenly had a lot more time to do #DFIR work, so I saw it as a chance to build my #DFIR skills up — something which I needed to do because malware, Windows, and, as it turned out, analysis techniques had advanced somewhat while I’d been busy doing other things. The only downside was that I wasn’t being paid to do it — something which, given I still had a mortgage, was eventually going to put a bit of a damper on the fun.
Now, if i was going to build my skills up I was going to need some malware to look at, so I built a virtual ‘lab’, set up a honeynet, and started this blog — that was just a couple of days past seven years ago now — to document my journey and to help any other budding malware analysts/forensic enthusiasts to learn with (or after) me.
The trouble is, I was still trying to analyse malware the way I’d always done it since the Stoned virus — loading it in to a debugger (ah, good old ‘debug.exe’!), disassembling it, and working out what it was doing from the disassembly, which is obviously a pretty slow process. I also noticed how long that process was taking me, and saw the rate at which my honeypot was collecting samples, and figured that I needed a better way.
So I bought some books, started reading, did some Internet searches, and discovered that malware analysis had also advanced somewhat while I’d been busy doing other things.
One of the advances that I discovered was that of a scriptable debugger (I think one of the books mentioned it) — winappdbg by Mario Vilas — so then when I noticed the same pattern of behaviour amongst a number of different malware samples — namely ‘unpacking’ code — I created my unpacking script, which would automatically save a copy of the unpacked code, along with some information about the location of the unpacking loop and the entry point of the unpacked code. You can read my introductory post for it, a follow-up post, and also a series on what it can tell you about CryptoLocker.
I’ve since added a number of features to my unpacking script — I need to tidy up a bit and push them to my github repository.
So, like I said, I’ve decided that it is time to launch what I’m calling ‘Life 2.0’, and get serious about pursuing a #DFIR career so that I can free up my non-work time for work like beekeeping and trying to convince vegetables to grow, and more traditional hobbies like music (I have a band performance at a major local sporting event in a few weeks and I’m not getting the time to practice — something which, if our last rehearsal is anything to go by, I really need to do!), unicycling, kayaking, and geocaching.
There are other goals that I’m not getting the time to achieve because I’m working full time as a security engineer and having to work on forensics and reverse engineering in my personal time. Goals like arranging music, maybe even composing some music, writing a book, remaking a movie, improving my cooking skills, doing some self-supported unicycle tours (including a charity ride), setting up large-scale vegetable production to help contribute toward a secure food supply, and general IT tinkering (which was how I started reversing malicious software).
Forensics and reverse engineering are work that I enjoy doing, something that I have been wanting to do for a very long time, and something that I want to be really good at.
I think I’m at a point in my career that’s comparable to the final year project in a university course — I’ve gained a lot of knowledge, and gained a lot of experience, now I want to see what I can do with it all.
Usually when I’m dabbling in forensics work I’m analysing a compromised Windows system. This time, however, I was using my forensic skills to investigate a potential problem with one of my bee hives (for a shorter version, try my beekeepers club presentation).
I’ve had an interest in forensics for some time — there’s something about the challenge of trying to work backward to figure out what happened to cause the current state of a system. This, as it turns out, is exactly what I needed to do when I couldn’t see a queen bee, nor any bee eggs (suggesting that the colony was queen-less), in one of my hives.
Forensics requires knowledge of how a system works, and knowledge about what information to gather from the system in its current state, and the use of logical reasoning to work out as much as you can about what happened.
Usually I’m forensically analysing compromised Windows systems, which involves looking at file system/disk artefacts like file time stamps, names, and locations; registry time stamps; running processes; and log data from both the compromised machine itself and from other network devices such as network proxies and DHCP servers.
This time, however, I put my forensic skills toward solving a different problem. Instead of trying to work out how a Windows system was compromised, I was trying to work out why one of my bee hives didn’t seem to be doing too well — granted, a completely different field, with different information and more of a requirement for protective clothing rather than for technical skills, but the basic forensic skills of identifying relevant information, knowledge of how the system works, and logical reasoning still applied.
So, it is late spring. A time when there should be lots of worker bees, quite a few drone (male) bees, and a queen bee that is quite enthusiastic about laying eggs to boost the number of bees in the colony.
The problem is that when I inspected the hive, bee numbers were down, I didn’t see a queen bee (which isn’t necessarily a problem — absence of evidence isn’t evidence of absence — the queen may have been there but I failed to spot her), but I didn’t see any freshly laid eggs/larvae either (the presence of which would have indicated that there was a queen bee a few days ago at least).
The question is, do I need to start worrying about this colony and think about using some brood from its very close neighbour colony to attempt to save it, because without recently laid eggs, the workers are unable to make a new queen.
Let’s look at what I knew about this hive/colony, and this is also a good time to mention that like with computer forensics, log data can be awfully useful (I liken it to a fire extinguisher — most of the time you don’t need it, but when you do, it can be awfully handy) as it gives you some history:
- There weren’t as many bees as I was expecting to see
- There wasn’t as much honey as I was expecting to see (there was less than was there on the previous inspection, at a time when the amount of honey should be increasing — this is where writing log data can be useful)
- I didn’t see the queen bee
- I didn’t see any recently laid eggs (uncapped brood)
- I had received information from the host of the hive stating that he had seen them swarm
I wasn’t expecting them to swarm (an activity which involves a large number of bees, along with the queen bee, leaving the hive en-masse to find a new home, and an activity which as a responsible beekeeper I’m supposed to attempt to prevent) because on the inspection a week or so before they had plenty of room free in the hive, and they even had two brood boxes (something that I did to try and prevent them from swarming this season) in which the queen could lay eggs. Consequently I was questioning whether the swarm that our bee host had spotted was in fact my bees until he pointed out that he saw them leave my hive!
Knowing that they swarmed though, and knowing when they swarmed, is awfully useful information, and information which I logged. I also log, for each inspection, whether or not I saw the queen bee; whether or not I saw recently laid eggs; the presence and location of any queen cells; and some rough (and rather subjective) indication of how much honey there was, amongst a few other things. This information came in handy, as we shall see in a moment.
This is where some knowledge about the system, in this case European honey bee colonies, comes in.
Bees (European honey bees) will tend to keep building honeycomb, building up bee numbers, and fetching nectar to make honey, until they run out of space in their home — a bit like how a lot of software will keep writing log data until your file system runs out of disk space. Beekeepers inspecting their hives and removing (in some cases excessive amounts of) honey would then be similar to something like logrotate rotating and deleting old log data.
Unlike software though, which tends to make quite the mess when it fills your file system, bees do something a lot more sensible in that about half of the colony will head off with the queen to find somewhere else to live — a process known as swarming (and one which tends to needlessly panic a lot of people, possibly because of all the cartoons which tend to incorrectly depict swarms of bees flying after people to attack them).
Swarming is a process which responsible beekeepers are supposed to try and prevent for two reasons — one being that a swarm of bees flying around the neighbourhood tends to needlessly panic people; and the other being that you lose about half of your bees and a reasonable quantity of honey (which the swarming bees will consume to produce beeswax that they’ll use to furnish their new home). I thought I had prevented my bees from swarming by leaving them plenty of room to grow their colony and to store nectar/honey, but they still chose to swarm for some reason.
Knowing that they swarmed though helps with points 1 and 2 above, in that it explains why both bee numbers and honey quantity are lower than expected.
When the bees are preparing to swarm, they will create a few queen cells. Queen cells are honeycomb cells that are somewhat larger than normal honeycomb cells — larger because they are going to be used to grow queen bees and queen bees are larger than worker and drone bees. When the bees create these queen cells, they generally produce them at the bottom of a frame of wax. This is why it is a good idea to log the presence of queen cells, and later on we’ll see why it is a good idea to log the location of the queen cells too.
The reason they create a few queen cells, when a colony will only tolerate one queen bee, is for the same reason a company will have two email/DNS servers and/or two Internet links — in case one fails. Unlike email servers though, the first queen bee to emerge from her cell will attempt to locate and kill off any remaining queen bees (a bit like how having more than one DHCP server on the same network will tend to create some carnage).
Conveniently, when it comes to European honey bees, there are certain known time frames:
- The length of time between a swarm leaving a hive and the new queen emerging from her queen cell
- The length of time to make a queen bee
- The length of time to make a worker bee
- The length of time between an egg being laid and its cell being capped
A normal swarm involves the bees creating queen cells along the bottom of a frame that will be used to house new queens for the bees that remain behind. Ultimately, only one of these queens will remain. The bees will then tend to swarm 2-3 days before the new queen is due to emerge from her cell.
Going through my log data, I was told that they swarmed on the 14th October. From the above fact we can deduce that the new queen should have emerged from her cell around the 16th-17th October.
It takes 16 days to make a queen bee, so now we can work back and deduce that the queen bee egg was laid around the 30th September-01st October.
Brood cells are usually capped around 9 days after the eggs are laid in the cells, so the last batch of uncapped brood from the old queen would have been capped around the 23rd October — nine days after the old queen left in the swarm on the 14th October.
New queens will mill around the hive for around 7-10 days before they are fit to leave the hive on a mating flight to mate with drone bees from another colony. Consequently the new queen wouldn’t have mated, and hence wouldn’t have laid any eggs, until the 24th-27th October — 7-10 days after emerging from her cell on the 17th October.
Now we should be able to work out a time frame during which we are unlikely to see any uncapped brood, being the time between 9 days after the old queen left with the swarm on the 23rd October, and the new queen returning from her mating flight around the 24th-27th October — a period of 1-4 days.
It just so happens that I checked the bees on the 27th October — right at the end of this ‘no uncapped brood’ period, and started panicking after not seeing any uncapped brood. No uncapped brood suggests that the colony no longer has a queen bee, and even worse, they don’t have any uncapped eggs/larvae that they can turn in to a queen bee.
I also noticed a queen cell with a hole in the side of it, which makes me wonder if that was the result of a newly emerging queen chewing through the side of it so that she can sting (to kill) the unhatched queen (apparently they do that!).
Remembering that there were certain time frames, and that it takes time for things to happen, I set about creating the time line that I just described. This time line highlighted that I was probably panicking a tad too early. I would have liked to have checked them the following weekend, because the new queen should have been laying eggs not long after I checked them on the 27th, but a combination of being away and work meant that I couldn’t check them again until the 11th November.
The inspection on the 11th November confirmed that I was prematurely panicking. There was uncapped brood again — not as much as I would have liked to have seen, but at least there was some (maybe the new queen hasn’t quite got the hang of laying eggs yet). I didn’t see any queen cells this time so it looks like the remaining bees are content to stay where they are for the moment.
It would still be good to actually see the queen though to confirm that the colony does have a queen and that it isn’t a rogue worker bee laying eggs, but bee numbers are up, as is the amount of stored nectar/honey, so I’ll leave them alone for a few weeks and let the colony build up bee and honey stores (hopefully enough so that I can steal some honey from them during the next inspection).
The funny thing is, and another reason why keeping logs of your bee inspections can be handy, is that when I went back through my log data, this pattern was very similar to that of last year — that is, there was an inspection last year, seven days after they swarmed, where I failed to see any uncapped brood, nor a queen. Then a second inspection also at the end of the new queen mating time frame, when I didn’t see any fresh brood, but I didn’t panic so much that time because I did see the queen.
Here is the completed time line that I was able to construct:
2018-09-09
Bee check:
Some capped and fresh brood in second brood box.
Didn't check bottom box because of the ambient temperature.
2018-09-22
Bee check:
Some capped and fresh brood in second brood box.
Mostly brood and pollen in bottom brood box, with one frame almost covered in capped brood.
Didn't seem to be as much brood as in hive B -- possibly aging queen.
Saw queen and fresh brood.
2018-10-01
Replacement queen laid
2018-10-04 - 2018-10-11
Emergency queen laid
2018-10-14
Swarm
2018-10-17
Queen hatches
2018-10-19
Bee check:
Some capped and fresh brood in second brood box.
Mostly brood and pollen in bottom brood box.
Queen cells in upper brood box, near top of frames and middle of frames so emergency cells.
Some pollen in the second brood box.
Quite a bit of pollen in bottom brood box.
Didn't see queen, but saw fresh brood.
Quite a bit of space free in the bottom brood box.
2018-10-23
Last batch of fresh brood from old queen
2018-10-24 - 2018-10-27
Queen ready to mate
2018-10-27
Bee check:
A few queen cells that have been broken open, so presumably hatched queens.
A queen cell with a worker bee sticking its head in the side of it -- I think it was slightly open at the end, but not enough for a queen to get out of I wouldn't have thought.
No fresh brood!
2018-10-27
Open emergency queen cells
2018-11-11
Bee check:
Some capped and uncapped brood in bottom brood box.
Didn't notice so many queen cells (even opened ones).
There was one that was open at the end.
We have fresh brood again, which is good.
Didn't see queen though.
So nothing to worry about, and a demonstration of how forensic techniques can be used to investigate a potential problem with bee hives.
Obviously the artefacts that you are looking for are different for IT forensics, but the process is very similar — look at what you have in the way of artefacts (such as when files and registry keys were modified; running processes; network connections), and use your knowledge of the system and how it works to determine the circumstances under which those artefacts are created/modified. Then string the circumstances together in a logical order to determine, as best as you can, what happened.
The WannaCry/WannaCrypt ransomware/worm struck late last week and wreaked havoc with a number of important files/documents being encrypted. Can a twenty year old idea of mine actually help to restrict the damage caused by ransomware by essentially ‘hiding’ your important files so that ransomware can’t find them?
After my tinkering with IT as a kid progressed to more of a hobby, followed by almost 22 years of full time employment as an IT engineer, I’m started to wonder if I’ve been a tad foolish.
I’m starting to think that there is more to life than IT (despite seeing more and more people that seem to think that it’s more important to walk around looking at the screen of their mobile phone rather than looking where they’re going), and with this realisation comes another realisation — that a life of IT has left me with very few practical life skills.
So now I find myself at a point where I want to do something that’s actually useful to people/society, but all I know how to do is IT.
I’m wondering how to implement ideas and make them a reality? How can I build (physical) things — how do you join pieces of wood for instance? How do businesses work?
How can I do something useful, and hopefully change lives — if not the world — when I don’t seem to be able to change a tap washer?!
The 06th March is the day that the Michelangelo virus (a virus I came across back in the early nineties) would overwrite disk sectors, and it apparently caused quite a frenzy back in January 1992. I was thinking, here we are 25 years later, and what have we done? (Look out — this is another one of my non-technical posts!) Continue Reading
There’s a theory that a thousand monkeys typing away at a thousand typewriters will eventually reproduce the works of Shakespeare. I got home one day to find a JavaScript downloader semi-randomly creating dynamic functions until one of them worked and downloaded some malware that I hadn’t seen before. Continue Reading
